Еще один сервер для 1С 7.7

[faqa]

Можно попробовать решить тупым увеличением сервера, памяти максимально поставить, чтобы базу скуля закешировать. Но без переделывания конфига все-равно упретесь в тупик. Впрочем, вариант переделки конфига на месяцы, а сервер можно собрать в течении 2-3 недель.

Переделывание конфига от нас никак не зависит. Посему будем тупо наращивать мощу сервака. Наверное утром Александр из Екабурга прочитает последние мессаги в этой ветке и как-нибудь отреагирует

[Ziggy Stardust]

Прикладываю файлик мониторинга за сегодняшние полдня. Что-то там тяжелое запускалось в конце дня (в районе 16-00 минут на 15). Но как выяснилось, практически все тяжелые операции у нас требуют блокировки базы, таким образом другие пользователи 1С уже ни одной проводки завершить не могут.

Пока видно что дисковые очереди время от времени сильно растут. Старенькие сказевики нагрузки не выдерживают. С современными SAS 15K и современным контроллером ситуация поправится в этом плане.

Загрузка проца тоже плотная довольно. Тут кстати не факт что современные ксеоны сильно помогут. Если загрузка идет от одного процесса, то от многоядерности и всяких гипер-трейдингов толку много не будет, все будет банально в тактовую частоту одного ядра упираться...

Т.е. вопрос сводится к тому, чтобы уменьшить время выполнения таких "тяжелых" операций. Самая длительная такая регулярная "тяжелая" операция длится примерно 2,5 часа. Она будет завтра вечером, можно ее тоже помониторить.

Да, надо обязательно посмотреть, чтобы точно убедиться в чем затык...

[faqa]

Распилил счетчик загруженности процессоров по ядрам (т.е. сейчас 4 счетчика - 2 проца по 2 ядра). Запустил на день. Завтра утром будут данные по тому "тяжелому отчету на 2,5 часа".

[faqa]

Появились очередные данные. По "тяжелому отчету на 2,5 часа". Начинается он вчера в районе 18-30. Прошу прощения, за много лишнего (ночные данные), не нашел сходу, как отпилить ненужное.

[Ziggy Stardust]

Очень плотно плющатся все ядра процессорные, в пиках до 100%. Правда при этом очеред процессорная не растет, но это скорее всего из-за последовательности обработки запросов, т.е. пока предыдущие не обработались, следующие и не начинаются.

Примерно такая же картина по загрузке процов наблюдается ночью, где то с 00:15 до 03:45.

Еще на короткие интервалы (минута-две) очень сильно возрастают дисковые очереди на запись. Видимо как процы справляются с очередной порцией данных, обработанная инфа начинает писаться в базу и тут уже дисковая подсистема несколько проседает.

Память свободная есть все время.

В общем напрашивается вывод, что просто напросто не хватает процессорной мощи... То что все 4 ядра заняты, это очень хорошо. Значит довольно хорошо паралелится счетная нагрузка и есть все шансы что два 4-х или 6-ти ядерника заметно помогут.

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

[faqa]

Примерно такая же картина по загрузке процов наблюдается ночью, где то с 00:15 до 03:45.

в это время идет резервное копирование базы

Еще на короткие интервалы (минута-две) очень сильно возрастают дисковые очереди на запись. Видимо как процы справляются с очередной порцией данных, обработанная инфа начинает писаться в базу и тут уже дисковая подсистема несколько проседает.

Память свободная есть все время.

Ну вот тут корифеи говорят, что чем больше - тем лучше - базу закешировать. Сейчас то система все равно больше 3,5 гига не видит.

В общем напрашивается вывод, что просто напросто не хватает процессорной мощи... То что все 4 ядра заняты, это очень хорошо. Значит довольно хорошо паралелится счетная нагрузка и есть все шансы что два 4-х или 6-ти ядерника заметно помогут.

Как-нибудь нашу предполагаемую конфигурацию в этом плане пересматривать будем?

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

К сожалению, тут глухо. Программеры - не наши (внешняя контора, обслуживающая у нас 1С). Если до сих пор, зная текущую ситуацию у нас, они ничего не сделали, то сейчас - и подавно. К тому же глобально заняты перетаскиванием конфиги на 8-ку. В общем тут повлиять на ситуацию весьма маловероятно. Как-то все работает - бухгалтерия и так рада.

[Ziggy Stardust]

Память свободная есть все время.

Ну вот тут корифеи говорят, что чем больше - тем лучше - базу закешировать. Сейчас то система все равно больше 3,5 гига не видит.

Ну вообще правильно.

В общем напрашивается вывод, что просто напросто не хватает процессорной мощи... То что все 4 ядра заняты, это очень хорошо. Значит довольно хорошо паралелится счетная нагрузка и есть все шансы что два 4-х или 6-ти ядерника заметно помогут.

Как-нибудь нашу предполагаемую конфигурацию в этом плане пересматривать будем?

Разве что процы с 5620 на 5650 поменять, они 6-ти ядерные будут и частотой пободрее несколько. Но и заметно дороже будут :-(

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

К сожалению, тут глухо. Программеры - не наши (внешняя контора, обслуживающая у нас 1С). Если до сих пор, зная текущую ситуацию у нас, они ничего не сделали, то сейчас - и подавно. К тому же глобально заняты перетаскиванием конфиги на 8-ку. В общем тут повлиять на ситуацию весьма маловероятно. Как-то все работает - бухгалтерия и так рада.

Ну в принципе тоже верно, чего щас с 7-кой упираться, если в скором времени все равно на 8-ку переходите.

[faqa]

Давайте, шлите, Александр, мне на мыло чего у нас в итоге получается?

[Ziggy Stardust]

Отправил. Видимо на последней конфигурации и надо остановиться.