Требования к серверу (аспект производительности)

[Quasar]

Здравствуйте!

Внедряю новую информационную систему на основе FB2. Встал вопрос о приобретении сервера. Почитав статьи и форумы, получил общее представление о требованиях к серверу базы данных. Но остались некоторые вопросы.

Прежде всего опишу специфику моей системы. Информация в базу данных будет заносится непрерывно в автоматическом режиме с АРМ, на которых стоят программы АСК (Автоматизированные Системы Контроля). Таких АРМ предполагается до 20-ти. Работают они в режиме 24х7. Ожидается рост БД около 0,5 Гб/год. Кроме этого будут отдельные модули по вводу сопутствующих данных, создания отчетов и стат обработки (в т.ч. OLAP), всего одновременно до 5-10 подключений. Статистику будут изучать боссы, поэтому несолидно если обработка данных будет тормозить. В добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК.

Теперь свои соображения. Поскольку обработка данных не должна тормозить работу модулей сбора информации, желательно делать Classic Server, потому что в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков. По той же причине целесообразно использование двухпроцессорной системы.

Вопросы:
Какая доля правды есть в моих соображениях?
Практикуется ли установка CS на однопроцессорных системах? (не факт, что сразу удастся вытребовать парочку)
Есть ли принципиальная разница в распараллеливании процессов между системой на двухядерном процессоре и двухпроцессорной системой?

Буду благодарен за любые советы, замечания, предложения. Это мой первый первый опыт во внедрении ИС с БД на производстве, поэтому хочется учесть как можно больше ньюансов, чтобы опыт был успешным.

Спасибо!

[hvlad]

В добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК

Именно поэтому никто и никогда не делает ввод данных с устройства в БД без промежуточного буфера

в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков.

Это где такая глупость написана ?

Вопросы:
Какая доля правды есть в моих соображениях?
Практикуется ли установка CS на однопроцессорных системах? (не факт, что сразу удастся вытребовать парочку)

Не большая
Практикуется

Есть ли принципиальная разница в распараллеливании процессов между системой на двухядерном процессоре и двухпроцессорной системой?

Не должно быть

[Quasar]

Именно поэтому никто и никогда не делает ввод данных с устройства в БД без промежуточного буфера

Хорошая идея, спасибо, реализую это с помощью ClientDataset.

Это где такая глупость написана ?

Это написано в книге Х.Борри в описании файла конфигурации. Может я что-то неправильно понял.
Цитирую:

PrioritySwitchDelay
...Устанавливается для планировщика потоков Windows. Целое число задает время в миллисекундах, которое должно пройти, прежде чем приоритет неактивного потока будет уменьшен до LOW или приоритет активного потока будет увеличен до HIGH. ...
PriorityBoost
... Это целое число задает количество доролнительных циклов, предоставляемых потоку, когда его приоритет переключается на HIGH. ...

[Ivan_Pisarevsky]

Полностью солидарен с Владом про "промежуточный буфер", датчики льют в текстовый файлы, потом демон на сервере подхватывает эти файлики и пихает в БД. При такой концепции ничего не потеряется, даже если сервер озадачить отчетом в несколько десятков минут.

Сейчас купить сервер с одноядерным камнем можно разве что на рапродаже лежалого товара, так что не парься 1 или 2 двуядерных камня (смотреть по бюджету), пару САС (или скази) шпинделей в зеркало (для начала), рэйд бери сразу, потом поверх этого добра классик версию ФБ и поехали.

[Dimitry Sibiryakov]

Ну а если случится такое маловероятное событие что мощности таки не будет хватать, то ставь две Жар-Птички: супер на влитие, классик на отчеты и какую-нибудь репликацию между ними. Причем на разные сервера. Заодно получишь горячий бэкап.

[hvlad]

Это где такая глупость написана ?

Это написано в книге Х.Борри в описании файла конфигурации. Может я что-то неправильно понял.
Цитирую:

PrioritySwitchDelay
...Устанавливается для планировщика потоков Windows. Целое число задает время в миллисекундах, которое должно пройти, прежде чем приоритет неактивного потока будет уменьшен до LOW или приоритет активного потока будет увеличен до HIGH. ...
PriorityBoost
... Это целое число задает количество доролнительных циклов, предоставляемых потоку, когда его приоритет переключается на HIGH. ...

Это не совсем так и не совсем про то

[Quasar]

Спасибо за советы!

Это не совсем так и не совсем про то

Если не сложно, конкретизируйте, пожалуйста, что там не так или ткните где можно прочитать, потому как в релиз ноутс написано то же самое.

[kdv]

В добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК.

почитай www.ibase.ru/devinfo/sys_failure.htm

Если не сложно, конкретизируйте, пожалуйста, что там не так или ткните где можно прочитать, потому как в релиз ноутс написано то же самое.

просто ЗАБУДЬ про эти параметры.

[hvlad]

Это не совсем так и не совсем про то

Если не сложно, конкретизируйте, пожалуйста, что там не так или ткните где можно прочитать, потому как в релиз ноутс написано то же самое.

Это workaround побочных эффектов взаимодействия нашего и windows планировщиков потоков.
Весьма вероятно, что в след. версиях его просто не будет.
Конкретнее могу отослать только к исходникам.

Исходная фраза

в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков

не верна, можете поверить мне на слово (или проверить самостоятельно )
Никакого длительного повышения приоритета потока не происходит

[Quasar]

Почитав статью "Classic против Super Server"http://www.interbase-world.com/ru/book/ ... _id=267813, стал думать в сторону организации сервера CS на Linux в ввиду лучшей организацией многозадачности, при которой не происходит подвисания при выполнения "тяжелого" вопроса.

... Если мы запускаем какой-то очень интенсивно работающий с базой запрос, то он выполняется в рамках одного серверного процесса, обслуживающего данного клиента, не останавливая при этом остальные. Приоритет "тяжёлого" запроса (фактически, процесса) падает по мере увеличения времени использования им ресурсов процессора и он начинает "уступать дорогу" более приоритетным процессам других соединений, выполняющим короткие запросы, т.е. процессор занят на 90%, но на долю "долгожителя" приходится 80-70-60-50-40%… Он замедляет остальных, это заметно, но терпимо, и главное - у пользователя не возникает ощущения "подвешенности". Правда, следует отметить, что такой эффект наблюдается только на InterBase с архитектурой Classic под Linux/Unix. ...

Действительно ли WinXP в этом смысле проигрывает Linux? Если это так, то выбор в пользу Linux в моем случае очевиден.

[Ivan_Pisarevsky]

Действительно ли WinXP в этом смысле проигрывает Linux? Если это так, то выбор в пользу Linux в моем случае очевиден.

WinXP - это десктопная ОСь, имеет смысл ставить поверх этой ОСи фб разве что для разработки или для конторы из пары-тройки компутеров, ну никак ни для серьезной нагрузки. У микрософта есть линейка серверных ОСей, хотя я бы сделал упор на линух, в качестве платформы для фб.