День добрый.
Вопрос я думаю уже платиновый, но вразумительного ответа так и не нашел.
Есть сервер. Старенький, но живой. На борту Xeon E1230, 16гб оперативки DDR3 с ECC. Мать интел, на ней есть софт рейд. Собственно еще давно сделал там 1 диск не в рейде под операционку и софт, 2 диска в зеркале под базы, 1 диск под обменник. Диски в рейде свежие WD Blue Sata 3, висят на 2х единственных 6гб портах. Диски же под хлам и систему Sata 2.
Изначально баз было штук 40, фирма оказывает консалтинговые услуги. Все базы были файловыми. В принципе пока была версия 8.2, все было суперотлично, потом с переходом на 8.3 все становилось хуже с каждым обновлением. И вот момент настал, в районе марта прошлого года, после обновлений базы стали открываться по 5 минут. Не помогало уже ничего, ни очистка кэша, ни пересчет индексов. И да, сами диски дефрагментируются по расписанию, так что это тоже не причина. Проверял скорость винтов - все гуд, в пределах нормы.
Собственно погрузившись в темные закоулки гугла, стало понятно что пришло время переходить на SQL. Прикупили MSSQL Server 12й и x64 сервер 1с. Настроил по гайдам sql и кластер, конвертировал базы, сама база на рейде, логи на диске с хламом. Отдал под sql 6гб оперативки, 9 под 1с, и гиг оставил ос. Регламентированные задачи настроил тоже.
После этих операций базы стали открываться буквально за минуту-полторы, никаких проблем.
Проблема же появилась буквально в октябре, после очередного обновления. Базы стали открываться все медленнее. Перерыл гугл, даже примерно не нашел ответа. В декабре же опять после обновления началась дичь. Во первых сервер сам начал работать натужнее, просто все даже открывается медленнее. В журнале sql сервера кучи ошибок выполнения регламентированных задач, при чем в тексте ошибки просто написано что вот на той базе споткнулся, просто потому-что. Периодически базы падают в режим восстановления и висят так по 5-10 минут. Ну и у пользователей соответственно вываливается что база не обнаружена, ошибка шаред мемори на натив клиенте sql, при этом нажав 3-4 раза повторить, все открывается, и работает без нареканий.
За праздники отрезервировал базы отдельно, в новый архив акрониса, дабы не путался с боевым. Попробовал пересоздать/переподключить базы, эффекта не дало. Но заметил такую вещь, когда кластер 1с отключен, все базы резко перестают уходить в восстановление, и работают весьма штатно, сервер вновь шустро бегает. Запускаю службу обратно, и все опять укатывается в болото.
У меня всего 3 варианта:
1. Обычные винты не вытягивают нагрузку.
2. Мало оперативной памяти.
3. Ошибки в конфигурации сервера.
Нужны ваши советы мудрые.
Вопрос я думаю уже платиновый, но вразумительного ответа так и не нашел.
Есть сервер. Старенький, но живой. На борту Xeon E1230, 16гб оперативки DDR3 с ECC. Мать интел, на ней есть софт рейд. Собственно еще давно сделал там 1 диск не в рейде под операционку и софт, 2 диска в зеркале под базы, 1 диск под обменник. Диски в рейде свежие WD Blue Sata 3, висят на 2х единственных 6гб портах. Диски же под хлам и систему Sata 2.
Изначально баз было штук 40, фирма оказывает консалтинговые услуги. Все базы были файловыми. В принципе пока была версия 8.2, все было суперотлично, потом с переходом на 8.3 все становилось хуже с каждым обновлением. И вот момент настал, в районе марта прошлого года, после обновлений базы стали открываться по 5 минут. Не помогало уже ничего, ни очистка кэша, ни пересчет индексов. И да, сами диски дефрагментируются по расписанию, так что это тоже не причина. Проверял скорость винтов - все гуд, в пределах нормы.
Собственно погрузившись в темные закоулки гугла, стало понятно что пришло время переходить на SQL. Прикупили MSSQL Server 12й и x64 сервер 1с. Настроил по гайдам sql и кластер, конвертировал базы, сама база на рейде, логи на диске с хламом. Отдал под sql 6гб оперативки, 9 под 1с, и гиг оставил ос. Регламентированные задачи настроил тоже.
После этих операций базы стали открываться буквально за минуту-полторы, никаких проблем.
Проблема же появилась буквально в октябре, после очередного обновления. Базы стали открываться все медленнее. Перерыл гугл, даже примерно не нашел ответа. В декабре же опять после обновления началась дичь. Во первых сервер сам начал работать натужнее, просто все даже открывается медленнее. В журнале sql сервера кучи ошибок выполнения регламентированных задач, при чем в тексте ошибки просто написано что вот на той базе споткнулся, просто потому-что. Периодически базы падают в режим восстановления и висят так по 5-10 минут. Ну и у пользователей соответственно вываливается что база не обнаружена, ошибка шаред мемори на натив клиенте sql, при этом нажав 3-4 раза повторить, все открывается, и работает без нареканий.
За праздники отрезервировал базы отдельно, в новый архив акрониса, дабы не путался с боевым. Попробовал пересоздать/переподключить базы, эффекта не дало. Но заметил такую вещь, когда кластер 1с отключен, все базы резко перестают уходить в восстановление, и работают весьма штатно, сервер вновь шустро бегает. Запускаю службу обратно, и все опять укатывается в болото.
У меня всего 3 варианта:
1. Обычные винты не вытягивают нагрузку.
2. Мало оперативной памяти.
3. Ошибки в конфигурации сервера.
Нужны ваши советы мудрые.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Единственно верный тут вариант ответа - денег. Будь у клиента деньги, не стоял бы старый сервер.
А так, без запущенных баз процессор 20% нагрузки, и около 4х гб оперативной памяти свободно. В нагрузке 5 клиентов-5 баз, процессор скачками до 50%, память максимум 500мб свободно. А вот жесткий диск почти всегда 100%, и это меня смущает как раз больше всего.
А так, без запущенных баз процессор 20% нагрузки, и около 4х гб оперативной памяти свободно. В нагрузке 5 клиентов-5 баз, процессор скачками до 50%, память максимум 500мб свободно. А вот жесткий диск почти всегда 100%, и это меня смущает как раз больше всего.
(4)когда база разрушится, чисто гипотетически допустим в пятницу, потеряется всего 5 дней работы. Я думаю это будет достаточно для нахождения денег на ссд, ну а мне новых клиентов.
>Раз 100 значит надо либо разносить базы на разные диски
Максимум где я еще один диск найду, это если рейд разберу.
>Раз 100 значит надо либо разносить базы на разные диски
Максимум где я еще один диск найду, это если рейд разберу.
Так как 1с практически весь код теперь исполняет не на клиенте а на сервере требования к серверу резко выросли.
Зная прожорливость 1с относительно памяти думаю что на сервере должна быть своя минималка + примерно по 500 МБ на каждую активную клиентскую машину... то есть если у вас например 100 клиентов то памяти на сервере не должно быть меньше 64 ГБ.
И кстати если раньше у нас на самих клиентах при памяти меньше 2 ГБ были проблемы, то сейчас даже удивились на клиентских машинах и с меньшим количеством памяти всё нормально работает.
Оперативной памяти 16 ГБ на сервере? Это шутка такая?
Зная прожорливость 1с относительно памяти думаю что на сервере должна быть своя минималка + примерно по 500 МБ на каждую активную клиентскую машину... то есть если у вас например 100 клиентов то памяти на сервере не должно быть меньше 64 ГБ.
И кстати если раньше у нас на самих клиентах при памяти меньше 2 ГБ были проблемы, то сейчас даже удивились на клиентских машинах и с меньшим количеством памяти всё нормально работает.
Оперативной памяти 16 ГБ на сервере? Это шутка такая?
(7) А формы управляемые в конфигурациях при этом есть?
Могу конечно ошибаться но как я понимаю если в коде написано &НаСервере и у вас SQL база а не файловая и формы управляемые то хоть тонкий клиент хоть толстый код будет исполняться на сервере...
Есть тут кто-нибудь кто этот вопрос точно знает?
И кстати уже сталкивался с тем что типовые конфигурации запущенные под SQL если их принудительно запускать в режиме толстого клиента начинают глючить.
Могу конечно ошибаться но как я понимаю если в коде написано &НаСервере и у вас SQL база а не файловая и формы управляемые то хоть тонкий клиент хоть толстый код будет исполняться на сервере...
Есть тут кто-нибудь кто этот вопрос точно знает?
И кстати уже сталкивался с тем что типовые конфигурации запущенные под SQL если их принудительно запускать в режиме толстого клиента начинают глючить.
(10)
(10)
(9)
Есть тут кто-нибудь кто этот вопрос точно знает?
Так и есть.
(10)
типовые конфигурации запущенные под SQL если их принудительно запускать в режиме толстого клиента начинают глючить
Глючить начинают из-за того, то в толстом клиенте нет модулей менеджера объектов (статических методов - по аналогии с другими языками программирования), к которым чуть ли не каждый объект типовых конфигураций обращается.
(9)
Если не сложно, можно слегка подробнее?
В последних рекомендациях от 1С есть инфа, что при высокой нагрузке на сервер приложений не плохо было бы перевести журналы регистрации обратно из LiteSQL в TXT-режим. Как это сделать - описано на всяких там ресурсах ИТС, инфостартах и прочих 1С-ных вместилищах...
Изначально баз 40. это уже не мало.
Как правило для компании такого рода деятельности необходим сервер по мощнее.
Конечно мой совет никак не решает вашу проблему оперативно. Но настоятельно рекомендую поменять сервер и хорошо бы с SSD дисками, очень положительно влияет на скорость работы. 6 гб выделять для СКЛ мало он ..ука прожорливый. поставьте как можно побольше оперативки. Сколько одновременных подключений к базам? и какое количество баз (ведь на каждой есть еще и не мало фоновых заданий)? средний статистический прирост баз за квартал или за год?
Как правило для компании такого рода деятельности необходим сервер по мощнее.
Конечно мой совет никак не решает вашу проблему оперативно. Но настоятельно рекомендую поменять сервер и хорошо бы с SSD дисками, очень положительно влияет на скорость работы. 6 гб выделять для СКЛ мало он ..ука прожорливый. поставьте как можно побольше оперативки. Сколько одновременных подключений к базам? и какое количество баз (ведь на каждой есть еще и не мало фоновых заданий)? средний статистический прирост баз за квартал или за год?
В общем и целом, я решил проблему.
Первым шагом - грохнул кеш сервера 1с. Базы стали открываться без задержки, но все равно с сообщением о том что база не обнаружена.
Вторым шагом - отключил все базы в sql, грохнул логи, подключил обратно. Все по одной. Сообщение о не существовании базы исчезли.
Но так-то это не решение, а чистой воды везение. Первым делом нужно разжиться ссд, а дальше уже по обстоятельствам. Переводом на txt, я займусь уже в следующие выходные.
Первым шагом - грохнул кеш сервера 1с. Базы стали открываться без задержки, но все равно с сообщением о том что база не обнаружена.
Вторым шагом - отключил все базы в sql, грохнул логи, подключил обратно. Все по одной. Сообщение о не существовании базы исчезли.
Но так-то это не решение, а чистой воды везение. Первым делом нужно разжиться ссд, а дальше уже по обстоятельствам. Переводом на txt, я займусь уже в следующие выходные.
40 баз ? Да это просто космос какой-то !
Лишним точно не будет следующее:
Для копий баз: Отключаем регламентные задания; Отключаем журналы регистрации;
Везде где можно - отключаем регламентные и журналы;
Переходим на более стабильную платформу: мои субъективные рекомендации
8.3.8.2167
8.3.10.2639
Некоторые платформы реально глючные;
Лишним точно не будет следующее:
Для копий баз: Отключаем регламентные задания; Отключаем журналы регистрации;
Везде где можно - отключаем регламентные и журналы;
Переходим на более стабильную платформу: мои субъективные рекомендации
8.3.8.2167
8.3.10.2639
Некоторые платформы реально глючные;
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот