Имеем терминальный сервер под win2008 (десктопная машина, i7, 4 Gb оперативки — довольно простая машина для 5-6 пользователей), пользователи используют 1с-Рарус, бд файловая, находится на этом же сервере.
1С ужасно тупит, особенно при запуске и когда что-нибудь формируют.
Перенесли БД на другую машину с raid 0 — тестировать скорость.
А прироста ни на грамм, специально замеряли: секунда в секунду закончился расчёт (что-то формировали).
Что, получается, что скорость обмена с винтом далеко не самый главный параметр для 1С?
посмотрел свой сервер, 1С 7.7, 4Gb ECC 2channel, 4 ядра, (мать серверная) Intel Q8400, Win2003x64 SP2, база около 1,6Гб, зеркало, юзеров 10, одновременно в базе порядка 4-5, во время отчетов заходят и работают все, тормозов особо не заметно. Если генерят отчеты большие, то оставляют на ночь.
Для файловой 1C приоритетней всего время произвольного доступа к файлу!
И рэйды не способствуют его снижению, напротив даже.
По этому тюним кэши файловой системы на сервере, и шевелим мозгами в сторону рапторов и SSD :-)
Ну и разгрести сетевое хозяйство. Ситуация когда неуправляемый свитч, на свитче сидит и свитчём погоняет, неприемлема!
По личному опыту, старенького core 2 duo c 4 гигами оперативы, и чёрным дятлом было достаточно что бы радовать пятерых бухов, файловой 1С.
А файловая 1С на RAM-диске, вообще жжет напалмом…
PS. А вообще и SQL сервер, тоже можно и нужно уметь правильно готовить!
о, а расскажите, пожалуйста, более подробно о результатах работы файловой 1С на RAM-диске? тесты какие-то проводили, чтобы сравнить? как часто, куда и каким образом снимали бэкапы? был ли диск дуплицирован как-нибудь on-line с физически другой машиной на случай bsod? сколько по времени система эксплуатируется, были ли сбои, как решались?
SADKO - не сочтите за труд, поделитесь опытом, если "файловая 1С на RAM-диске" это тоже самое что и ядро системы в РАМ-памяти, то я хотя бы знаю куда копать, с БД не встречался.
@Gor6a4eB Думаю, Sadko имел ввиду, когда в ОС создаётся виртуальный диск, который размещается в оперативной памяти. На него помещается файловая БД.
В итоге, имеем просто дикие скорости доступа и чтения файлов, в много-много раз быстрее современных SSD, но и головную боль: файлы на диске в RAM надо постоянно синхронизировать с каким-то другим накопителем, иначе BSOD, либо любой другой сбой ОС (например потеря питания) - и данных просто нет.
Раньше на ebay мелькала такая штука как Gygabyte i-RAM, устройство, которой из планок памяти DDR делало по сути тот самый винчестер, вот только не помню, чем оно "в сторону" ОС смотрело, видимо SATA (PCI не берём в расчёт). Сейчас таких устройств как-то меньше стало...
Ох-ты сколько вопросов, в общем так @nitro80 прав, хотя я пробовал и аппаратные устройства, но RAM диск оказалось дёшево, сердито и надёжно...
Надёжно потому что он легко копируется прямо во время работы и если что-то пошло не так, вернуть всё в зад...
Дело в том, что вероятность внезапной потери доступа к файлу совсем не нулевая и в файловой 1С там некое подобие журналирования записей, так что можно тупо копировать на живую хоть каждую минуту.
А по ночам делался апдейт инкрементного архива который копировался в файловое хранилище с Raid5. Так-же в случае отказа встроенного харда, снимки RAM писались в хранилище, а заинтересованные лица получали уведомление.
1. Добавить озу (8, лучше 16 гб)
2. Купить ссд на 128, разбить на 2 диска на 1 диск система (не забыть сделать образ), на 2й 1С.
3. Покупается обычный винт, например WD Green. Из диска с 1С делаются ежедневные бекапы.
При такой системе должно нормально работать.
самое простое откройте диспетчер задач и посмотрите нагрузку на процессор и память. Если памяти не хватает и все лезет в своп то ставим памяти ещё.
Если проца не хватает меняем проц на более быстрый, чувствую я 1с использует только одно ядро для формирования отчета.
дальше надо мониторить винты с помощью утилиты perfmon
откуда вы взяли что ваш рейд0 будет быстрее на рандомном чтении я не знаю. возьмите один ссд и погоняйте на нем.
Никакой супер мощный сервер не спасет от говнокода, 1С не такая уж медленная если её правильно приготовить конфигурация написана грамотно, найдите действительно хорошего программера, который найдет узкие места вашей конфигурации и предложит что и как можно улучшить. 5Гб это не такая уж и большая база, чтобы сильно тормозить.
В принципе, файловый режим быстрее SQL-ного, но на малом числе юзеров < 5.
Если БД файловая и активно работают порядка 10 — то тормоза всяко будут, даже на базе в 1.5Гб.
Т.е. здесь однозначно на сервер приложений+SQL. Можно юзать MS, можно бесплатный postgres и DB2, но они медленне MS процентов на 20-30.
По железу — как правло критична память и диск. Для диска классный вариант SSD винты зеркалом (только обязательно зеркалом, а то статистики по надежности нет почти)
месяца два назад у двух разных клиентов, полетели SSD на серверах, работали зеркалом. наработка в среднем была около 1 года по одному клиенту и около 1,5 лет по другому клиенту, один работает в сфере ЖКХ (проработал SSD около 1 года в бухгалтерии), другой клиент в сфере соц.услуг (проживание для инвалидов и ветеранов), также сервер для бухгалтерии. Ладно бэкапы были, не смертельно. Но сам факт нифига не радует.
