Требования к серверу (аспект производительности)
Требования к серверу (аспект производительности)
Здравствуйте!
Внедряю новую информационную систему на основе FB2. Встал вопрос о приобретении сервера. Почитав статьи и форумы, получил общее представление о требованиях к серверу базы данных. Но остались некоторые вопросы.
Прежде всего опишу специфику моей системы. Информация в базу данных будет заносится непрерывно в автоматическом режиме с АРМ, на которых стоят программы АСК (Автоматизированные Системы Контроля). Таких АРМ предполагается до 20-ти. Работают они в режиме 24х7. Ожидается рост БД около 0,5 Гб/год. Кроме этого будут отдельные модули по вводу сопутствующих данных, создания отчетов и стат обработки (в т.ч. OLAP), всего одновременно до 5-10 подключений. Статистику будут изучать боссы, поэтому несолидно если обработка данных будет тормозить. В добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК.
Теперь свои соображения. Поскольку обработка данных не должна тормозить работу модулей сбора информации, желательно делать Classic Server, потому что в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков. По той же причине целесообразно использование двухпроцессорной системы.
Вопросы:
Какая доля правды есть в моих соображениях?
Практикуется ли установка CS на однопроцессорных системах? (не факт, что сразу удастся вытребовать парочку)
Есть ли принципиальная разница в распараллеливании процессов между системой на двухядерном процессоре и двухпроцессорной системой?
Буду благодарен за любые советы, замечания, предложения. Это мой первый первый опыт во внедрении ИС с БД на производстве, поэтому хочется учесть как можно больше ньюансов, чтобы опыт был успешным.
Спасибо!
Внедряю новую информационную систему на основе FB2. Встал вопрос о приобретении сервера. Почитав статьи и форумы, получил общее представление о требованиях к серверу базы данных. Но остались некоторые вопросы.
Прежде всего опишу специфику моей системы. Информация в базу данных будет заносится непрерывно в автоматическом режиме с АРМ, на которых стоят программы АСК (Автоматизированные Системы Контроля). Таких АРМ предполагается до 20-ти. Работают они в режиме 24х7. Ожидается рост БД около 0,5 Гб/год. Кроме этого будут отдельные модули по вводу сопутствующих данных, создания отчетов и стат обработки (в т.ч. OLAP), всего одновременно до 5-10 подключений. Статистику будут изучать боссы, поэтому несолидно если обработка данных будет тормозить. В добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК.
Теперь свои соображения. Поскольку обработка данных не должна тормозить работу модулей сбора информации, желательно делать Classic Server, потому что в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков. По той же причине целесообразно использование двухпроцессорной системы.
Вопросы:
Какая доля правды есть в моих соображениях?
Практикуется ли установка CS на однопроцессорных системах? (не факт, что сразу удастся вытребовать парочку)
Есть ли принципиальная разница в распараллеливании процессов между системой на двухядерном процессоре и двухпроцессорной системой?
Буду благодарен за любые советы, замечания, предложения. Это мой первый первый опыт во внедрении ИС с БД на производстве, поэтому хочется учесть как можно больше ньюансов, чтобы опыт был успешным.
Спасибо!
Re: Требования к серверу (аспект производительности)
Именно поэтому никто и никогда не делает ввод данных с устройства в БД без промежуточного буфераQuasar писал(а):В добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК
Это где такая глупость написана ?Quasar писал(а):в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков.
Не большаяQuasar писал(а):Вопросы:
Какая доля правды есть в моих соображениях?
Практикуется ли установка CS на однопроцессорных системах? (не факт, что сразу удастся вытребовать парочку)
Практикуется
Не должно бытьQuasar писал(а):Есть ли принципиальная разница в распараллеливании процессов между системой на двухядерном процессоре и двухпроцессорной системой?
Хорошая идея, спасибо, реализую это с помощью ClientDataset.hvlad писал(а):Именно поэтому никто и никогда не делает ввод данных с устройства в БД без промежуточного буфера
Это написано в книге Х.Борри в описании файла конфигурации. Может я что-то неправильно понял.hvlad писал(а):Это где такая глупость написана ?
Цитирую:
PrioritySwitchDelay
...Устанавливается для планировщика потоков Windows. Целое число задает время в миллисекундах, которое должно пройти, прежде чем приоритет неактивного потока будет уменьшен до LOW или приоритет активного потока будет увеличен до HIGH. ...
PriorityBoost
... Это целое число задает количество доролнительных циклов, предоставляемых потоку, когда его приоритет переключается на HIGH. ...
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Полностью солидарен с Владом про "промежуточный буфер", датчики льют в текстовый файлы, потом демон на сервере подхватывает эти файлики и пихает в БД. При такой концепции ничего не потеряется, даже если сервер озадачить отчетом в несколько десятков минут.
Сейчас купить сервер с одноядерным камнем можно разве что на рапродаже лежалого товара, так что не парься 1 или 2 двуядерных камня (смотреть по бюджету), пару САС (или скази) шпинделей в зеркало (для начала), рэйд бери сразу, потом поверх этого добра классик версию ФБ и поехали.
Сейчас купить сервер с одноядерным камнем можно разве что на рапродаже лежалого товара, так что не парься 1 или 2 двуядерных камня (смотреть по бюджету), пару САС (или скази) шпинделей в зеркало (для начала), рэйд бери сразу, потом поверх этого добра классик версию ФБ и поехали.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Это не совсем так и не совсем про тоQuasar писал(а):Это написано в книге Х.Борри в описании файла конфигурации. Может я что-то неправильно понял.hvlad писал(а):Это где такая глупость написана ?
Цитирую:PrioritySwitchDelay
...Устанавливается для планировщика потоков Windows. Целое число задает время в миллисекундах, которое должно пройти, прежде чем приоритет неактивного потока будет уменьшен до LOW или приоритет активного потока будет увеличен до HIGH. ...
PriorityBoost
... Это целое число задает количество доролнительных циклов, предоставляемых потоку, когда его приоритет переключается на HIGH. ...
почитай www.ibase.ru/devinfo/sys_failure.htmВ добавок, работа модулей отчетов и стат обработки ни при каких условиях не должны загружать БД настолько, чтобы тормозился ввод данных с АСК.
просто ЗАБУДЬ про эти параметры.Если не сложно, конкретизируйте, пожалуйста, что там не так или ткните где можно прочитать, потому как в релиз ноутс написано то же самое.
Это workaround побочных эффектов взаимодействия нашего и windows планировщиков потоков.Quasar писал(а):Если не сложно, конкретизируйте, пожалуйста, что там не так или ткните где можно прочитать, потому как в релиз ноутс написано то же самое.hvlad писал(а):Это не совсем так и не совсем про то
Весьма вероятно, что в след. версиях его просто не будет.
Конкретнее могу отослать только к исходникам.
Исходная фраза
не верна, можете поверить мне на слово (или проверить самостоятельно )Quasar писал(а):в случае SuperServer, поток, производящий длительную операцию, в течение установленного времени получает приоритет HIGH, чем тормозит работу остальных потоков
Никакого длительного повышения приоритета потока не происходит
Почитав статью "Classic против Super Server"http://www.interbase-world.com/ru/book/ ... _id=267813, стал думать в сторону организации сервера CS на Linux в ввиду лучшей организацией многозадачности, при которой не происходит подвисания при выполнения "тяжелого" вопроса.
Действительно ли WinXP в этом смысле проигрывает Linux? Если это так, то выбор в пользу Linux в моем случае очевиден.... Если мы запускаем какой-то очень интенсивно работающий с базой запрос, то он выполняется в рамках одного серверного процесса, обслуживающего данного клиента, не останавливая при этом остальные. Приоритет "тяжёлого" запроса (фактически, процесса) падает по мере увеличения времени использования им ресурсов процессора и он начинает "уступать дорогу" более приоритетным процессам других соединений, выполняющим короткие запросы, т.е. процессор занят на 90%, но на долю "долгожителя" приходится 80-70-60-50-40%… Он замедляет остальных, это заметно, но терпимо, и главное - у пользователя не возникает ощущения "подвешенности". Правда, следует отметить, что такой эффект наблюдается только на InterBase с архитектурой Classic под Linux/Unix. ...
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
WinXP - это десктопная ОСь, имеет смысл ставить поверх этой ОСи фб разве что для разработки или для конторы из пары-тройки компутеров, ну никак ни для серьезной нагрузки. У микрософта есть линейка серверных ОСей, хотя я бы сделал упор на линух, в качестве платформы для фб.Quasar писал(а):Действительно ли WinXP в этом смысле проигрывает Linux? Если это так, то выбор в пользу Linux в моем случае очевиден.