Григорий Ненашев (все сообщения)

Как говориться, пора открыть ветку вакансии, возможно у многих возникает вопрос о поиске сотрудников по данным направлениям.

Если у кого есть открытые вакансии, пишем сюда.
В описание вакансий прошу подробно описывать должностные обязанности.

"По закрытию вакансии прошу отписываться"

А там по-другому никак, т.к код нужно править фикса. Штатными средствами системы никак, а что именно нужно менять по каким условиям?

Цитата
George Menegakis пишет: Hello, My name is George M. Menegakis (http://h30499.www3.hp.com/t5/user/vie...-id/919792 ) and once upon a time a was a very active participant (Pharaoh Level) of ITRC forum. I was delighted to find that OVSD is still in use. Since this is a Russian forum I read your messages through google translate and if you like I would love to participate, though only in english.

Предлагаю тему развернуть «Наши пользователи»
У кого какие случаи звонков от пользователей реальные были поделитесь…

Когда у меня была такая проблема, я частично перевел правила с Scheduled Tasks на JOB. Переписал полностью все правила DB на более оптимальные. Удалил 80% правил UL и перевел их на работу через бизнес логику системы.
Одно правило UL заменило % 60 правил на ограничение, в замен, того что было. Также оптимизировал базу для поиска, например если в поисковой форме где номер указывается в промежутке поиск работал, скажем сек 6 теперь 1 сек. Т.е стал работать как я бы искал через расширенную форму поиска с однозначным условием.
Для всех представлений как системных так и пользовательских на кастумные поля добавил индексов. (часто используемые в представлениях) Тогда представление у пользователей грузиться мгновенно,
Зависание app серверов происходит крайне редко. – Что не может не радовать, я их даже не перезапускаю автоматически. По прикладам это 6 серверов для работы с пользователями и 2 для почты.
Мне кажется, что зависание происходят из-за DB правил, простой пример, хотим видеть всех активных специалистов в онлайне по группе: В карточку заносим поле типа персонал, пишем правило на внесение в это поле сотрудника который изменил форму, и DB правилом уже пишем дату изменения в карточку пользователя. Вот теперь если специалист будет групповой правкой в объектах что-то править, то мы вызываем чумовую нагрузку на данное правило… может привести к зависанию сервиса. (проверял, работает).. «Есть свои нюансы».

В общем, это тоже является поводом для увеличения серверов. На самом деле где-то мы обсуждали этот вопрос.

Кто-то поступает иначе, поднимает на одном APP сервере еще один, но при этом придется сломать одну табличку, чтобы сервесы запустились.
Кстати, а в чем заключается торможение? Можно привести статистику нагрузки на APP на SQL, На диски, и т.д. Причиной торможения не обязательно будет APP сервер.
Вот, например, простой пример, когда пора добавлять сервер:
Запустили групповою правку на изменения поле статус, а в системе есть DB правило которое следит за этим полем и делает какие-то действия. По факту поле изменилось, а правило не отработало. При этом, нужно учитывать сколько было подключено пользователей к данному app серверу.

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

Но также нужно и учитывать нагрузку на базу. Если нагрузка большая, и системе дать еще одну кобылку, то тут встанет вопрос, а почему нагрузка на базу большая? Так что, для начала советую взглянуть на производительность.