Народ, кто сталкивался с такой штукой?Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку и закинуть туда все базы, то при работе с самой большой базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери данных. Если же одну из основных баз перенсти на другой комп то все работает хорошо.
Вопрос такой, если сделать не одну расшаренную папку а несколько и в каждую из них поместить базу - решит ли это проблему или нет? Попробовал был сам, но на эксперементы возможности нет =(
Вообще-то советуют все базы раскидывать по разным шарам...имхо стоит это сделать>Народ, кто сталкивался с такой штукой?
>
>Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку
>и закинуть туда все базы, то при работе с самой большой
>базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери
>данных. Если же одну из основных баз перенсти на другой комп
>то все работает хорошо.
>
>Вопрос такой, если сделать не одну расшаренную папку а несколько и в
>каждую из них поместить базу - решит ли это проблему или
>нет? Попробовал был сам, но на эксперементы возможности нет =(
>Вообще-то советуют все базы раскидывать по разным шарам...имхо стоит это сделать
>
>>Народ, кто сталкивался с такой штукой?
>>
>>Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку
>>и закинуть туда все базы, то при работе с самой большой
>>базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери
>>данных. Если же одну из основных баз перенсти на другой комп
>>то все работает хорошо.
>>
>>Вопрос такой, если сделать не одну расшаренную папку а несколько и в
>>каждую из них поместить базу - решит ли это проблему или
>>нет? Попробовал был сам, но на эксперементы возможности нет =(
Да вот в общем так и хочу пока сделать, но нужен какой то практический опыт одного из отвечающих =) А то порвут если перенесу и будет работать плохо =(Просто тут вопрос вот в чем. Два копа держат две базы, 2 шары держат по базе на одном компе - это равносильное решение или все таки отличается?
>Народ, кто сталкивался с такой штукой?
>
>Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку
>и закинуть туда все базы, то при работе с самой большой
>базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери
>данных. Если же одну из основных баз перенсти на другой комп
>то все работает хорошо.
>
>Вопрос такой, если сделать не одну расшаренную папку а несколько и в
>каждую из них поместить базу - решит ли это проблему или
>нет? Попробовал был сам, но на эксперементы возможности нет =(
1C SQL
>>Народ, кто сталкивался с такой штукой?
>>
>>Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку
>>и закинуть туда все базы, то при работе с самой большой
>>базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери
>>данных. Если же одну из основных баз перенсти на другой комп
>>то все работает хорошо.
>>
>>Вопрос такой, если сделать не одну расшаренную папку а несколько и в
>>каждую из них поместить базу - решит ли это проблему или
>>нет? Попробовал был сам, но на эксперементы возможности нет =(
>
>
>1C SQLFreeBSD =)
Но даже если перетащить все на винду, нужно временное решение =(
>>>Народ, кто сталкивался с такой штукой?
>>>
>>>Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку
>>>и закинуть туда все базы, то при работе с самой большой
>>>базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери
>>>данных. Если же одну из основных баз перенсти на другой комп
>>>то все работает хорошо.
>>>
>>>Вопрос такой, если сделать не одну расшаренную папку а несколько и в
>>>каждую из них поместить базу - решит ли это проблему или
>>>нет? Попробовал был сам, но на эксперементы возможности нет =(
КОНЕЧНО НЕ ПОМОЖЕТ!!! Проблемы возникают из-за ограничений дисковой подсистемы ОДНОЙ ФИЗИЧЕСКОЙ МАШИНЫ, и пропускной спобности ОДНОЙ СЕТЕВОЙ КАРТОЧКИ на той самой ОДНОЙ физической машине! И сделай ты хоть 100 шар под каждый файл, все упрется либо в сетку, либо в винт!
>>>Народ, кто сталкивался с такой штукой?
>>>
>>>Есть 23 базы разных, основных две. Вот если сделать одну расшаренную папку
>>>и закинуть туда все базы, то при работе с самой большой
>>>базой начинаются проблемы в виде долгих формирований, зависаний, ошибок и потери
>>>данных. Если же одну из основных баз перенсти на другой комп
>>>то все работает хорошо.
>>>
>>>Вопрос такой, если сделать не одну расшаренную папку а несколько и в
>>>каждую из них поместить базу - решит ли это проблему или
>>>нет? Попробовал был сам, но на эксперементы возможности нет =(
>>
>>
>>1C SQL
>
>FreeBSD =)Ошибаешься. Решение давно есть на постгресе.
>Но даже если перетащить все на винду, нужно временное решение =(
Мы тут не винду обсуждаем.
> Ошибаешься. Решение давно есть на постгресе.
Это для 1С версии 8.1 А если у человека 23 базы то это на 100% - 7.7
Я конечно не юзал 23 базы одновременно, но я думаю что ему поможет выделение еще одного ПК для больших баз (их 2-3) и оставить мелкие (т.е. около 20) на первом сервере, конечно же есть смысл перейти на 1Гб сеть. Кстати SQL не обязательно повысить скорость работы 1С (для маленькой базы - да, для достаточно большой - нет). SQL однозначно повысить отказоустойчивость. Можно попробовать использовать терминальный доступ, что-бы повысить скорость обработки некоторых отчетов (например бух. формирует в конце месяца баланс), отчет сформируется быстрее, остальные почти не почувствуют тормозов.
>> Ошибаешься. Решение давно есть на постгресе.
>Это для 1С версии 8.1 А если у человека 23 базы то
>это на 100% - 7.7
>Я конечно не юзал 23 базы одновременно, но я думаю что ему
>поможет выделение еще одного ПК для больших баз (их 2-3) и
>оставить мелкие (т.е. около 20) на первом сервере, конечно же есть
>смысл перейти на 1Гб сеть. Кстати SQL не обязательно повысить скорость
>работы 1С (для маленькой базы - да, для достаточно большой -
>нет). SQL однозначно повысить отказоустойчивость. Можно попробовать использовать терминальный доступ, что-бы
>повысить скорость обработки некоторых отчетов (например бух. формирует в конце месяца
>баланс), отчет сформируется быстрее, остальные почти не почувствуют тормозов.Для 7.7 тоже естьSQL решения на мускуле или постгресе, а не только на mssql. Но суть не в этом, как правильно заметил один из авторов постов - проблемы две - диск и сеть.
В общем, сначал определи, какой у тебя объем баз. Если он шагнул за Гиг, пора сворачиваться и переходить на SQL. При таком количестве баз это не просто разумно - это жизненно необходимо.
Если базы, ососбенно основные, не многим более полугига, тогда решений несколько:
1) Повысить производительность дисковой подсистемы, переведя все это счастье на SCSI raid
2) Повысить пропускную способность сети при помощи установки новых сетевых карт, правки smb.conf и вешания разных клиентов на доступ к разным ip(лучший способ - сегментирование сети)
3) Установка гигабитки
4) Установка дополнительно сетевых карт + что-то типа ng_fec + умный свитч который умеет работать с транками.Все выше перечисленные способы подразумевают под собой наличие нормальных свитчей, а не хабов, так же их нормальной настройки, что бы не вели себя как последний хаб.
Хотя смотреть надо по ситуации.
>>> Ошибаешься. Решение давно есть на постгресе.
>>Это для 1С версии 8.1 А если у человека 23 базы то
>>это на 100% - 7.7
>>Я конечно не юзал 23 базы одновременно, но я думаю что ему
>>поможет выделение еще одного ПК для больших баз (их 2-3) и
>>оставить мелкие (т.е. около 20) на первом сервере, конечно же есть
>>смысл перейти на 1Гб сеть. Кстати SQL не обязательно повысить скорость
>>работы 1С (для маленькой базы - да, для достаточно большой -
>>нет). SQL однозначно повысить отказоустойчивость. Можно попробовать использовать терминальный доступ, что-бы
>>повысить скорость обработки некоторых отчетов (например бух. формирует в конце месяца
>>баланс), отчет сформируется быстрее, остальные почти не почувствуют тормозов.
>
>Для 7.7 тоже естьSQL решения на мускуле или постгресе, а не только
>на mssql. Но суть не в этом, как правильно заметил один
>из авторов постов - проблемы две - диск и сеть.
>В общем, сначал определи, какой у тебя объем баз. Если он шагнул
>за Гиг, пора сворачиваться и переходить на SQL. При таком количестве
>баз это не просто разумно - это жизненно необходимо.
>Если базы, ососбенно основные, не многим более полугига, тогда решений несколько:
>1) Повысить производительность дисковой подсистемы, переведя все это счастье на SCSI raid
>
>2) Повысить пропускную способность сети при помощи установки новых сетевых карт, правки
>smb.conf и вешания разных клиентов на доступ к разным ip(лучший способ
>- сегментирование сети)
>3) Установка гигабитки
>4) Установка дополнительно сетевых карт + что-то типа ng_fec + умный свитч
>который умеет работать с транками.
>
>Все выше перечисленные способы подразумевают под собой наличие нормальных свитчей, а не
>хабов, так же их нормальной настройки, что бы не вели себя
>как последний хаб.
>Хотя смотреть надо по ситуации.
Спасибо всем за советы. Будем пробовать.
>Для 7.7 тоже естьSQL решения на мускуле или постгресе, а не только
>на mssql.
А где? Я видел и пробовал только бэтту на 8.1
>>Для 7.7 тоже естьSQL решения на мускуле или постгресе, а не только
>>на mssql.
>А где? Я видел и пробовал только бэтту на 8.1
На нескольких фирмах в стольном граде Киеве имеется.
>На нескольких фирмах в стольном граде Киеве имеется.
Вы ссылку то дайте (лучше в прайсе 1с). А то смахивает на игру Дюна-3 все играли, но никто не давал переписать 8).
>>На нескольких фирмах в стольном граде Киеве имеется.
>Вы ссылку то дайте (лучше в прайсе 1с). А то смахивает на
>игру Дюна-3 все играли, но никто не давал переписать 8).
В прайсе 1С нету, есть тока самопалы.