Развернул Сервер 1С предприятие на Ubuntu 12.04.
( дней полет был нормальный, а сегодня как с ума сошел началась подтупливать 1с-ка, харды шумят не переставая, если до этого все запускалось и работало летая, то сейчас при запуске легкое задумывание 1с, не активны кнопки в меню, потом начинает работать. htop показывает кучу запущенных 1с-ких процессов, некоторые их них процессор подъедает и причем сильно, подскажите в чем причина может быть?
что можно попробовать:
1. перезапустить службу сервера (если поможет, то с помощью какого-нить шедулера реализовать ежедневный перезапуск службы в нерабочее время).
2. если не помогло 1) проанализировать сеансы по процессам (может какие-то фоновые задания грузят сервер, например), проанализировать характер активности СУБД. например, с помощью sp_who в ms sql, если субд postgres, то поискать что-то аналогичное там.
(1) Shaka13, сначала опиши что за железо, БД на чем крутится, если sql база, какая база, работает на одном сервере с 1с сервером или на виртуалках.
проверь нагрузку на сам сервер в течения дня, загрузка проца, сколько оперативки кушает, и обращение к жестким, и хорошо бы протестировать сами диски.
(1) Shaka13, Начните поиск с ошибок в конфигурации, смахивает на не корректные запросы и ошибки в кодах обработки деревьев или рекурсивных алгоритмов,
вторая возможная причина начал выходить из строя или вышел из строя один или несколько дисков массива
(25) alex_sh2008, причин может несколько, не правильно настроен postgresql, на одной машине крутится 1с сервер и БД, желательно развести на несколько машин, мало оперативки, проблема с железом, также ошибки в коде БД 1с.
(26) Aleksey58, один ответ нашел:
Q111: При старте в логе вот такое сообщение: "MSD FATAL: the database system is starting up". Как исправить эту ошибку?
A111: На самом деле - это не ошибка. Просто PostgreSQL ругается, что к нему делаются попытки подключиться, хотя он ещё только запускается.
только у меня в логе fatal the database system is shutting down postgresql
сейчас отматываю назад все шаги, понимаю, что когда установил только постгри все перезапускалось без проблем, когда создал базу данных и выгрузил в нее нашу, сервис перестал останавливаться, кстати на виртуалке, сейчас вспоминаю так же было, вот тут скорее затык и возник.
(25) alex_sh2008, как проверить конфигурация, я не одинэсник. ук меня была такая мысль по поводу кривых запросов, но как проверить даже и не знаю, но знаю криворукость одинэсников вероятность большая. ( диски новые, собран программный рейд1 mdadm молчит в плане сбоев.
я(26) Aleksey58, я выше писал что пишет, просто перезагружать каждый раз сервер не камильфо, боюсь можно базу потерять, тогда будет трындец )
оперативки 16 гигов я выше писал, железо 64 битно, но все развернул 32 битное, возможно это узкое место, но free выдает использование около 3 гигов плюс минус. когда пошла утечка начала память естся до 4 гигов. разносить по разным машинам рабочий серврер не есть хорошо, надо все останавливать. спешка пошла, т.к. мне не дали до конца настроить и протестировать машину, начали давить. теперь я разгребаю все.
сейчас задача разобраться как корректно остановить службу постгри, т.к. stop не дает результата. как его оптимизровать, и возможно ли изменить настройки без перезапуска тем же самым reconfigure. в статьях приводятся настройки для серверов с 2-4 гига оперативки, есть ли смысл увеличивать пропорционально значения.
собран программный рейд1 mdadm молчит в плане сбоев.
- вот это и есть признак тормозов сервера, и тем более райд 1, если нет возможность поставить аппаратный рэйд, то удалите этот рейд, и сделайте два отдельных диска на одном поставьте 1С с sql а на втором делайте архивные копии чем чаще тем лучше
(30) Shaka13, Вы определитесь у вас утечка памяти или тормоза, возможно это во все не утечка а нормальный режим работы, и соответственном из этого надо исходить.
(31) alex_sh2008, rphost съедает до 80% CPU вы считаете это нормально? сейчас тормозов меньше стало после перезагрузки сервера позавчера, думаю дней через 5 потребуется снова. сейчас задача с постгри разобраться и в запросах конфигурации.
(32) Shaka13, Теперь однозначно проблема в конфигурации, нужно теперь отследить в какой момент происходит загрузка процессора и тем самым отследить участок где эта ошибка
(34) Shaka13, Вариант, попросить пользователя что бы он запомнил момент когда начались торможения, при загрузке, создании документа, формировании отчета и т.д.
(35) alex_sh2008, в htop видно -pid абракадабра ) процесса, но как его связать с конкретным пользователем и что он делает. у нас коллектив древний, глубоко сомневаюсь, что он сможет внятно что-то сказать, не то что сделать :( я могу посмотреть какие документы пользователи создавали редактировали, плюс нам меняли расходную накладную добавляли новые поля, возможно там есть косяк.
(38) Shaka13, то что вы написали то и смотреть, выгрузить базу и на своем компьютере по тестировать, если компьютер зависнет на какой нибудь операции ткнете носом программистов. А вообще то можно и не париться, а поставить им задачу пусть копаются сами
(39) alex_sh2008, я понял, мы почему перешли на сервер, т.к. база за 1,5 года до 4,5 гигов разраслась и по сети было сложно работать, на локальной машине в целом нормально работало. да и восмерошников толковых у нас нет, судя по ошибкам, какие они допускают. я могу конечно разобраться но на это надо время, а его нет, боюсь что все это хозяйство не рухнуло.
(42) Shaka13, А это вопрос спорный, всегда можно найти замену. Вам же не обязательно работать с местными, если они вас не устраивают работайте с другими удаленно.
(52) oermolaev, никого не хочу обидеть, но практика показывает, что на курсах 1с первое занятие начинается с того, что объясняют, при возникновении проблем в работе программы обвиняйте всегда сервер! с разными компниями и с разного уровня специалистами их этих компаний сталкивался, причем специалисты были разного уровня, даже те, которые были востребованы и записаться можно было за полгода вперед, фраза виноват сервер, это коронная, причем через время вылезает это в виде бага, который исправили в платформе.
здесь налицо 2 броблемы - это утечка амяти в платформе, и что-то неладное в PSQL.
в данный момент проблем с железом не выявлено, если бы оно было, я бы уже знал об этом, тем более за этим следит iLO и mdadm
но практика показывает, что на курсах 1с первое занятие начинается с того, что объясняют, при возникновении проблем в работе программы обвиняйте всегда сервер!
Оптимизация производительности - это всегда компромисс, между возможными затратами и ожидаемым эффектом, между теоритическим максимумом и реальными потребностями.
Преподаватели, возможно, повторяют заученную фразу, возможно не хотят вдаваться в детали, но смысл этой рекомендации немного другой.
В основном, под этой фразой подразумевается, что самый быстрый и наименее затратный способ повышения производительности - модернизация аппаратной части.
Если время терпит, то можно спокойно сесть, собрать, а потом и начать анализировать планы наиболее затратных запросов, для последующей оптимизации. Но, стоит учитывать, что это долгий кропотливый процесс, а средний сервер = зарплата программиста за 2-3 месяца работы.
И уж точно не надо думать, что какой либо из этих методов самый правильный, только их разумное сочетание дает ощутимый результат.
Еще один немаловажный момент - состояние сервера. Сколько раз сталкивался либо с криво настроенным железом, либо криво настроенным сервером СУБД, либо с полным отсутствием регламентных процедур на СУБД, либо все вместе сразу...
(54) h00k, что вы имеете ввиду - криво настроенное железо?
В основном, под этой фразой подразумевается, что самый быстрый и наименее затратный способ повышения производительности - модернизация аппаратной части.
если есть баг в платформе 1С как модернизация аппаратной части позволит его исправить? Мой сервер позволяет максимально поставить 192 гига оперативки и добавить еще один процессор, это решит проблему?
по поводу СУБД согласен, задача новая для меня поэтому сейчас впитываю информацию гигобайтами :)
я думаю надо идти от простого к сложному, отсекать поэтапно. есть прецентдент, есть вводные данные и исходя из этого надо плясать.
предлагаю абстрагироваться от аппаратной части, а сконцентрироваться на программной. а то мы в холивар скатываемся а конкретики никакой не прозвучало до сих пор.
В основном это касается включенных функций энергосбережения в биос и в плане электропитания ос, ну и как результат - очень тормознутый, но зато экономный сервер. Вот тут можно почитать подробнее http://infostart.ru/public/147259/ .
если есть баг в платформе 1С как модернизация аппаратной части позволит его исправить?
Это замечание касалось конфигураций, а баги в платформе, по крайней мере критичные, исправляются вполне оперативно. Другое дело, что из-за них, иногда, приходится ставить тестовые сборки платформы, не дожидаясь официального релиза... и внимательно следить за обновлениями.
Ну а вы, скорее всего, столкнулись с неправильно работающими фоновыми заданиями, из-за которых подвисают и плодятся процессы rphost. Точно определить проблему можно при помощи тех журнала.
Если я с ошибкой угадал, то временное решение - отключить все фоновые задания. Или можно попробовать отловить "проблемные" фоновые задания, на которых возникает ошибка.
Мой сервер позволяет максимально поставить 192 гига оперативки и добавить еще один процессор, это решит проблему?
При установке оперативки надо быть аккуратным и внимательно смотреть на характеристики процессора. Если поставить много планок памяти, например по 3 планки на канал, то можно словить падение производительности из-за снижения тактовой частоты RAM.
С доп. процессором все еще веселее: чем больше процессоров - тем чаще контекстные переключения - тем ниже линейная скорость выполнения задач. Так что, если есть возможность, то лучше использовать 1 многоядерный процессор. По крайней мере, скорость работы сервера с 1 многоядерным процессором будет немного выше, чем сервера с 2 процессорами и таким же количеством ядер.
а конкретики никакой не прозвучало до сих пор.
А какая нужна конкретика? Действия вроде очевидны - обновить платформу до последней версии 8.3.5.1186. Если ошибка проявится - настроить сбор логов технологического журнала или, если вдруг есть купленная версия КИП, то попробовать "отловить" ошибку через него.
(28) Shaka13, "оперативки 16 гигов я выше писал, железо 64 битно, но все развернул 32 битное, возможно это узкое место"
с этого и надо было танцевать, у тебя система не позволяет больше 3.5 гигов оперативки предоставить, тебе нужно на x64 битную переходить, можно конечно ухитрится заставить чтобы все память использовать но как стабильно будет работать гарантию не кто не даст.
Но это решать тебе.
наверное причина "Развернул Сервер 1С предприятие на Ubuntu 12.04", мои подозрения 1С мало того под винду хрен что как надо допилила, а под линукс и подавно
все крутиться на одном сервере. железо hp proloant dl360e gen8 оперативки 16 гигов.
1с версии 8.3.5.1119 postrgesql 9.0.4 от etersotf
2 sas диска по 300 гигов собранный в программный raid1 все стоит на ubuntu server 12.04.5.
до сегодня оперативки съедало около 3 гигов, сегодня начало расти и уже чуть более 4 стало.
использованного дискового пространства было 3% сегодня стало уже 4%, хотя это связано может и с тем что ведется работа и данные растут.
конфигураия УНФ допиленная, может 1сники кривые запросы делали не знаю как проверить?
делал рестарт демона 1с проблема не ушла, сделал ребут сервера проблема ушла, завтра посмотрю на поведение ) до перезагрузки процесс rphost 1совксий съедал до одного ядра, 25%, диски шумели как сумашедшие.
я не настраивал сервер через консоль возможно там можно что-то настроить, что именно пока не знаю, буду признателен за инфу.
(7) Shaka13, я не знаком со спецификой настройки сервера под linux
ежедневный перезапуск службы сервера сделать стоит, ИМХО (как это сделать на linux не знаю, на win просто в штатном шедулере добавляешь задачу net stop и net start для службы 1С).
если повторится ситуация с высокой нагрузкой, то нужно разбираться дальше, что именно грузит сервер. какой-то аналог perfmon на linux есть? добавьте стандартные счетчики производительности - посмотрите. плюс в момент высокой нагрузки посмотреть на сеансы на сервере 1С, возможно начинают работать какие-то "тяжелые" фоновые задания...ну и т.д.
но в данной ситуации перезапуск службы 1с не решил проблему и если честно впервые слышу о необходимости ежедневного перезапуска сервиса или это фича 1с?
(9) Shaka13, много где рекомендуется регулярно перезапускать службу(если график работы с базой это позволяет)...иначе возможно получить проблемы, например, с утечками памяти. погуглите эту тему...информации достаточно.
а в данной ситуации, что произошло после перезапуска службы? снова сразу же появилась высокая нагрузка на процессор от rphost?
и если честно впервые слышу о необходимости ежедневного перезапуска сервиса или это фича 1с?
Скорее всего это следствие ошибок в сервере 8.3.5.1119 - резкий рост количества rphost, на 8.3.5.1146 эта ошибка так же существует. Рестарт сервера - один из способов решения проблемы.
(12) h00k, я тоже так подумал, 1с любят грешить утечкой памяти, тем более запросов с этой ошибкой в поиске куча, правда решения нет, интересно, какая платформа без этого бага?
рестарт сервера это не очень кашерно )
(13) Shaka13, у тебя БД на postgresе, посмотри настройки конфига postgresql.conf, для каждого сервера этот конфиг по своему настраивается, по настройке в инете полно описаниии, а тестирование сервера 1с воспользуйся тестами от Гилева http://www.gilev.ru/monitor/ .
(15) Shaka13, это многовато, а лучше всего 1с сервер и БД разделить, хотя бы на виртуалки перенести, т.к. сам 1с съедает хорошо, у меня самого БД крутится на postgresql, но я разделил на виртуалки.
По настройки postgresql есть хорошая книжка http://rating.kuzstu.ru/assets/docs/qms/postgresql-v3.pdf.
service postgresql restart через 1,5 минуты выдает FAILED т.е. не перезапускается, сейчас ищу причину почеу
в логах fatal the database system is shutting down postgresql
service srv1cv83 restart повторюсь в третий раз нет не помогает)