Модернизация сервера под 1С 7.7

[-=Жека=-]

если реально хотите решить задачу по 1С, то нужно сделать следующее.

терминально следует подключать только пользователей использующих 1С в SQL конфигурации.
если у Вас 20 конектов, то это примерно 200-400 мегабайт в памяти для каждого пользователя.
dbf ный 1С требователен к количеству одновременно открытых файлов и буферов на сервере. Плюс к этому идет нагрузка на процессор при формировании отчетов, отсюда и тормоза.
Выносите за пределы файлового 1С и SQL 1C терминальный сервер.
Для файлового 1С необходимо поменять настройки tcp/ip стека и увеличить количество одновременно открытых файлов.
для SQL сервера при размере базы 7GB, и размере оперативы 3GB нужно как минимум разнести базы и логи на разные диски, по хорошему нужен RAID 10 для каждого раздела. это увеличит скорость в 2-10 раз.

Если вышеуказанные требования сделать не получается, то оставьте существующий сервер как терминальный и купите новый сервер с возможностью расширения памяти до 16 GB. По поводу дисков можно использовать внешнюю дисковую SAS/SATA полку.

[pоmkа]

Неверные сведения по объемам баз предоставил. Основная база SQL 3.5 Gb.

[gs]

Чем поможет внешняя полка, если там сата?

[-=Жека=-]

Неверные сведения по объемам баз предоставил. Основная база SQL 3.5 Gb.

В любом случае разнос Tlog и базы данных на разные диски/каналы для SQL конфигурации, иначе это утопия.

[gs]

Не надо таких категоричных советов. Разнесение базы и логов массивам конечно полезно... когда речь идет про десятки шпинделей...

[-=Жека=-]

Не надо таких категоричных советов. Разнесение базы и логов массивам конечно полезно... когда речь идет про десятки шпинделей...

я не говорю категорично. я говорю про то, что реально помогает.
SWAP + SQL + TLOG на одном диске это утопия.
лучший вариант это разнести на разные каналы и на разные диски.
в противном случае будут тормоза которые снимут с вашей системы до 60% быстродействия.

[a_shats]

-=Жека=-
Расскажите, пожалуйста, каким образом разнесение винтов на разные каналы, если этих самых винтов менее 16, поможет в плане производительности. С подробностями, если возможно.

[gs]

Особенно чем поможет разнесение по каналам

[-=Жека=-]

-=Жека=-
Расскажите, пожалуйста, каким образом разнесение винтов на разные каналы, если этих самых винтов менее 16, поможет в плане производительности. С подробностями, если возможно.

вкратце.
имеем 1С SQL + 1С dbf расположенную на одном сервере на одном диске.

при работе с dbf, 1С позиционируется в каждом файле до 20 раз в секунду перечитывая индексы и выдергивая данные.
1C SQL 7.0 это тот же самый 1C DBF который засунут в SQL базу.
Обработка данных в 1C SQL идет путем бегания курсора по записям внутри таблиц. Никаких специфических процедур работы в 1С 7.0 SQL нету в принципе.

При недостатке памяти и размере баз больше имеющегося объёма начинается свап на диск для компенсации недостатка. Тут-то оно и встречается само с собой. Разнесение по разным дискам свапа, логов и баз это наилучший вариант развития событий. Также как разнос активных баз на разные носители во избежании задержек в позиционировании. теперь добавляем к этому всему DBF базы и пытаемся поработать. причем тут 16 дисков я не совсем понял, если только речь не идет насчет полки. Обычной скази без кеширования там не хватит. Контроллеры желательно иметь с памятью выше 128 мегабайт, хотя бы для кеширования файловых таблиц. речь не только по 1С SQL

[gs]

Слишком много букв и мало понимания как работают дисковые системы...

[-=Жека=-]

ок. вам наверное виднее, а я лох. посоветуйте тогда человеку поставить пару кластеров для файловой 1с вместо конкретных предложений решения проблемы.

[gs]

Наверно придется рассказать азы.
1. Мощь современных контроллеров (и даже предыдущего поколения) превосходит предельные иопсы всех подключенных к ним дисков буквально в разы.
2. Согласно п.1, при наличии современного и правильно сконфигуренного контроллера, производительность системы упирается в шпиндели.
3. Раскладка нагрузки, имеющей примерно одинаковый характер, по разным массивам существенного эффекта не дает. Контроллер сам прекрасно способен разобраться куда, когда и что писать. В редких случаях некоторые контроллеры предпочитают работать с массивами из малого числа дисков (так фирмварь написана), но это игры на уровне +-10%, к тому же зависит от КОНКРЕТНОЙ модели контроллера и характера нагрузки - угадать сложно.
4. В некоторых случаях можно поиграться параметрами кэширования лунов, созданных на одном массиве (ну и по ним разложить данные) - но это тоже довольно скользкий момент. Но это в общем-то резонно - по крайней мере хуже точно не будет, а может и малёхо полегчает.
5. Разнесение по массивам может дать и отрицательный эффект - если неверно угадаете раскладку нагрузки. Таки это ручная балансировка, в отличие от автоматической, которую делает контроллер.
6. Эффект разнесения по массивам начинается при существенном количестве дисков (хотя бы десятка полтора и больше). Там уже не так велик риск "не угадать". К тому же много винтов в один лун все равно не влезет - когда речь идет про десятки шпинделей, разносить нагрузку приходится само собой. И там это вполне оправдано.
7. Размер кэша - не панацея. В большинстве случаев вполне достаточно банальных 128МБ. Суть в том, что кэш глотает только всплески нагрузки, а в конечном счете винты все равно должны успеть это проглотить до следующего всплеска. Т.е. какой бы ни был кэш, если винты не дают нужную сумму иопсов, то получим ровный график дисковой очереди в десятки-сотни единиц.
8. Разнесение дисков-массивов по каналам контроллера при транзакционной нагрузке с точки зрения скорости ВООБЩЕ не имеет никакого значения. Несколько каналов нужны контроллеру только чтобы подключить много дисков без риска нарваться на нестабильность шины или другие канальные проблемы.
9. ИТОГО. Для увеличения дисковой производительности нужно просто много дисков в рэйд10 и достаточно мощный контроллер. Все остальные игры - это из области куда более серьезных систем.
10. То, что Вы говорите автору - это не советы, а просто фигня какая-то...

[gs]

Все это справедливо для систем, где мало дисков (этак до десятка). Ибо если у тебя три рубля, то как их по карманам не раскладывай, на сигареты не хватит...

[a_shats]

вкратце.
имеем 1С SQL + 1С dbf расположенную на одном сервере на одном диске.

при работе с dbf, 1С позиционируется в каждом файле до 20 раз в секунду перечитывая индексы и выдергивая данные.

Ну да ? А фраза "файловый кэш ОС", мимо которого приложения типа 1С работать просто не умеют - ничего не говорит ?

1C SQL 7.0 это тот же самый 1C DBF который засунут в SQL базу.
Обработка данных в 1C SQL идет путем бегания курсора по записям внутри таблиц. Никаких специфических процедур работы в 1С 7.0 SQL нету в принципе.

А Вы в курсе, как сам SQL работает, и до каких ему именно лампочек, какой клиент к нему обращается ? И как работает кэширование SQL ? И как он работает с дисковой ? Почитайте документацию (BOL), там все написано.

При недостатке памяти и размере баз больше имеющегося объёма начинается свап на диск для компенсации недостатка. Тут-то оно и встречается само с собой. Разнесение по разным дискам свапа, логов и баз это наилучший вариант развития событий.

Понятно. О том, что ОЗУ под SQL можно зафиксировать - Вы тоже не в курсе. "Свопообразный" процесс действительно имеет место быть в ситуации, когда хот-спот (наиболее активно используемая часть) БД не лезет в кэш страниц SQL (т.е. много страниц постоянно вытесняется и перечитывается (!) в страничный кэш) - но своп-файл к этому процессу не имеет ни малейшего отношения.

Также как разнос активных баз на разные носители во избежании задержек в позиционировании. теперь добавляем к этому всему DBF базы и пытаемся поработать. причем тут 16 дисков я не совсем понял, если только речь не идет насчет полки.

Чисто для себя почитайте про логику работы RAID-контроллеров. Сюрприз будет. Особенно по части "позиционирования".
16 потому что с меньшим числом винтов нет смысла играться в раскладывание нагрузки по винтам - RAID-контроллер это сделает намного эффективнее. Тем более, что ни ОС ни Вы не имеете никакого представления, где именно на самом деле в массиве находится искомый страйп (не блок и не сектор ! Еще сюрприз). А контроллер - имеет. И инженеры, его делавшие, в отличие от Вас, имеют опыт, измеряемый десятилетиями, разработки фирмвари контроллеров и разруливания падающих на них нагрузок.

Обычной скази без кеширования там не хватит. Контроллеры желательно иметь с памятью выше 128 мегабайт, хотя бы для кеширования файловых таблиц. речь не только по 1С SQL

Видите ли, RAID-контроллеру все таблицы в т.ч. файловые - по барабану, он от ОС получает блоки и отдает блоки. А MSFT вообще в ОЗУ кэшируется.

А я таки просил рассказать, чем это раскладка винтов по каналам поможет. Потому что не знаю таких SCSI-интерфейсов, у которых упор при нагрузке вида случайный доступ мелкими блоками в пропускную интерфейса  :D  Нет, ну может, они и были лет 10 назад - но никак не сейчас  :D

[-=Жека=-]

вкратце.
имеем 1С SQL + 1С dbf расположенную на одном сервере на одном диске.

при работе с dbf, 1С позиционируется в каждом файле до 20 раз в секунду перечитывая индексы и выдергивая данные.

Ну да ? А фраза "файловый кэш ОС", мимо которого приложения типа 1С работать просто не умеют - ничего не говорит ?

Запустите анализатор трафика на сетевом интерфейсе и посмотрите что делает 1С когда работает с шарой(например tshark,ethereal). Вы сильно удивитесь. особенно в мультипользовательской работе по сети.

1C SQL 7.0 это тот же самый 1C DBF который засунут в SQL базу.
Обработка данных в 1C SQL идет путем бегания курсора по записям внутри таблиц. Никаких специфических процедур работы в 1С 7.0 SQL нету в принципе.

А Вы в курсе, как сам SQL работает, и до каких ему именно лампочек, какой клиент к нему обращается ? И как работает кэширование SQL ? И как он работает с дисковой ? Почитайте документацию (BOL), там все написано.

Кеширование имеет место быть. В памяти живут не все данные.
Речь изначально шла о том, КАК заставить нормально работать 1C SQL + 1C DBF на одном сервере с 3Гигами рама и SQL базами превышающими доступную физическую память. Когда речь идет об одной базе никаких проблем нет. Я же говорю о 50-100 рабочих базах расположенных на одном сервере.

При недостатке памяти и размере баз больше имеющегося объёма начинается свап на диск для компенсации недостатка. Тут-то оно и встречается само с собой. Разнесение по разным дискам свапа, логов и баз это наилучший вариант развития событий.

Понятно. О том, что ОЗУ под SQL можно зафиксировать - Вы тоже не в курсе. "Свопообразный" процесс действительно имеет место быть в ситуации, когда хот-спот (наиболее активно используемая часть) БД не лезет в кэш страниц SQL (т.е. много страниц постоянно вытесняется и перечитывается (!) в страничный кэш) - но своп-файл к этому процессу не имеет ни малейшего отношения.

no comments. речь не об этом.

Также как разнос активных баз на разные носители во избежании задержек в позиционировании. теперь добавляем к этому всему DBF базы и пытаемся поработать. причем тут 16 дисков я не совсем понял, если только речь не идет насчет полки.

Чисто для себя почитайте про логику работы RAID-контроллеров. Сюрприз будет. Особенно по части "позиционирования".
16 потому что с меньшим числом винтов нет смысла играться в раскладывание нагрузки по винтам - RAID-контроллер это сделает намного эффективнее. Тем более, что ни ОС ни Вы не имеете никакого представления, где именно на самом деле в массиве находится искомый страйп (не блок и не сектор ! Еще сюрприз). А контроллер - имеет. И инженеры, его делавшие, в отличие от Вас, имеют опыт, измеряемый десятилетиями, разработки фирмвари контроллеров и разруливания падающих на них нагрузок.

В данном посте речь шла о 2х SCSI дисках на 36GB. Я не занимаюсь разработкой контроллеров хотя по образованию схемотехник. Мне хватило во времена моей учебы в вузе делать то, чего не могли до меня сделать в течении 5 лет.

Обычной скази без кеширования там не хватит. Контроллеры желательно иметь с памятью выше 128 мегабайт, хотя бы для кеширования файловых таблиц. речь не только по 1С SQL

Видите ли, RAID-контроллеру все таблицы в т.ч. файловые - по барабану, он от ОС получает блоки и отдает блоки. А MSFT вообще в ОЗУ кэшируется.

А я таки просил рассказать, чем это раскладка винтов по каналам поможет. Потому что не знаю таких SCSI-интерфейсов, у которых упор при нагрузке вида случайный доступ мелкими блоками в пропускную интерфейса  :D  Нет, ну может, они и были лет 10 назад - но никак не сейчас  :D

проведите эксперимент ради интереса. возьмите 30 бухгалтеров которые будут работать в 200 базах в общем доступе на обычном сказевом зеркале )

я не спорю что использование RAID контроллера (на чем больше дисков тем лучше) с достаточным кешем  даст фору на многих операциях нежели штатное сказевое зеркало.

Но !
Использовать RAID5 для записи-чтения Transaction Logs это глупо и расточительно. Использовать RAID5 для хранения баз скорее правило надежности, хотя не для всех правила являются руководством к действию.

Теперь по поводу 16 дисков на контроллерах.
у меня стоят 2 SuperMicro платформы на 15 хардов с 3ware 9550SX-16 на борту. Одна из платформ забита под завязку, вторая на 2/3.
Так вот есть интересный факт, при залитии туда SQL ных баз ежедневно в размере до 100 гигов за раз, после ночной проверки контроллер матерился на ошибки найденные и исправленные на дисках. Это было на RAID5 в большом количестве, и в меньшем на RAID10. После того как количество файлов на RAID5 собранном на 8 дисках перевалило за 2.5 миллиона скорость доступа к файлам заметно упала. Дефраги уже не помогают. Результатов тестирования IOmeter'ом я так и не дождался.


Дабы не быть голословным по поводу 1С, ниже скриншот с папки с базами.