OTRS.ru

Здравствуйте, для начала вводные
OTRS поднят на windows server 2012 R2, база postgresql 9.3, версия OTRS 3.3.8

Проблема 1. в закладке support assessment в закладке БД ошибка: Check "System Time" vs "Current Timestamp".
There is a material difference (28800 seconds) between application server (1421960230) and database server (1421931430) time.

Проблема 2. В заявке при попытке ответить всем, выбираю пункт "новый ответ", должно открыться окно ответа. Открывается секунд 15-30.

Почему-то связываю проблему 1 со второй. Может ли оно быть связано друг с другом и как решить хотя бы первую проблему, потому как со второй происходят какие-то странности. Периодически оно начинает открываться окно быстро, как и должно.

Основная "проблема" - это запуск OTRS на Win. Для нормально промышленного использования и дальнейшей доработки и развития win-платформа категорически не годится.
1. Вы пишете, что всё стоит на Win, тогда почему система видит, что сервер БД на отдельном сервере?
2. Связь с п.1 может и есть, но в целом это очень похоже на проблему общей производительности. Надо тестировать под нагрузкой с мониторингом всех элементов инфраструктуры, чтобы понять, где могут быть тормоза.
Не мучайтесь, поставьте из пакетов на CentOS всё на один сервер, и будет Вам счастье.

Основная "проблема" - это запуск OTRS на Win. Для нормально промышленного использования и дальнейшей доработки и развития win-платформа категорически не годится.
1. Вы пишете, что всё стоит на Win, тогда почему система видит, что сервер БД на отдельном сервере?
2. Связь с п.1 может и есть, но в целом это очень похоже на проблему общей производительности. Надо тестировать под нагрузкой с мониторингом всех элементов инфраструктуры, чтобы понять, где могут быть тормоза.
Не мучайтесь, поставьте из пакетов на CentOS всё на один сервер, и будет Вам счастье.

По поводу 1 ошибки - время ОС и время БД отличаются. То есть если Вы поменяете время в системе, то не факт, что но сменится и в базе данных. У меня так было, когда мы перешли на зимнее время. Пришлось искать команду, которая синхронизировала время MySQL и время системы. Мне помогла инфа отсюда. Вам же надо искать аналоги для PostgreSQL. По поводу 2 проблемы могу сказать, что у меня были тормоза в интерфесе, но из-за того, что я не включил обработчик perl-скриптов в apache2. После того, как я это сделал, интерфейс перестал тормозить.

И соглашусь с Алексеем, желательно вам переходить на линукс, тем более, что уже есть готовый образ системы, который можно развернуть на виртуальной машине, можно сказать, под ключ. Удачи!

По тормозам в интерфейсе нашел что ему не хватает Акселератора, поставил mod_perl для моей версии, ошибка в Ассестменте пропала, но тормоза остались, все таки связываю тормоза с этой рассинхронизацией по времени. Попробую Вашу ссылку на Винде и на Дебиан, посмотрю как оно себя будет вести в разных средах.
А по большому счету даже не знаю стоит ли оставаться на ОТРС ибо сейчас им пользуются внутренние сотрудники в количестве 5 человек, а планируют туда загнать внешних клиентов в колличестве около 500, вот и думаю, выдержит ли ОТРС такой наплыв пользователей или нет...

У меня более 500 клиентов держит прекрасно без всяких тормозов.

Уважаемый ТС, сделайте себе подпись, чтобы былр понятно, что у Вас за система и окружение.

со временем более-менее разобрался - понял куда копать, снизил разницу - вместо 65к секунд теперь 25к секунд.
Отловил почему долго открываются окна - при любых действиях в системе сильно подгружается процесс Апача. Может ли это быть из-за того что я для него докрутил модуль mod_perl?
тесту ради поднял еще оду виртуалку на винде, накатил ОТРС со сторонним обработчиком Перла (ActivePerl) - работает существенно веселее, однако не хочет принимать и отправлять письма ругаясь на неизвестную версию Перла. странно.
на виртуалке с дебианом тормоза такие же. Явно проблема с Апачем. Надо либо копаться с Апачем и выяснять в чем проблема с ним либо переводить с Апача на IIS, однако я пока не могу понять, если я перенесу обработку сайта на IIS, будет ли обрабатываться почта (не знаю, проблема почты на винде из-за другого Перла или из-за IIS).

Что посоветуете?

Что такое за время - 25 секунд? У вас компания такая секретная, что даже скриншоты обрезанные не можете показать?

Check "System Time" vs "Current Timestamp".
There is a material difference (25200 seconds) between application server (1422397869) and database server (1422372669) time.

25к секунд. Было 68к секунд.


Попробовал заставить работать OTRS через IIS - все ок опять же кроме почты
Backend ERROR: OTRS-CGI-63 Perl: 5.16.1 OS: MSWin32 Time: Tue Jan 27 17:31:37 2015 Message: POP3S: Can't connect to pop.gmail.com RemoteAddress: 192.168.10.249 RequestURI: /otrs/index.pl?Action=AdminMailAccount;Subaction=Run;ID=2;ChallengeToken=U3hV9w8ugIQ4xg9soaBBoT9VjPHZgkiT; Traceback (3768): Module: Kernel::System::MailAccount::POP3::Fetch (OTRS 3.3.8) Line: 127 Module: Kernel::System::MailAccount::MailAccountFetch (OTRS 3.3.8) Line: 427 Module: Kernel::Modules::AdminMailAccount::Run (OTRS 3.3.8) Line: 64 Module: Kernel::System::Web::InterfaceAgent::Run (OTRS 3.3.8) Line: 871 Module: PerlEx::Precompiler::c_::otrs::otrs::bin::cgi2dbin::index_pl::__ANON__ (unknown version) Line: 41 Module: (eval) (unknown version) Line: 458 Module: PerlEx::Precompiler::Execute (unknown version) Line: 458

ActiveState Perl - работает с IIS
Пробую Strawberry - internal server error 500.

1. Запустите в Support Assesement SQL benchmark и покажите, что он говорит.
2. Включите Журнал производительности и посмотрите реальную скорость исполнения скриптов.
3. Посмотрите с помощью браузера скорость передачи страниц.

Baok писал(а):Пробую Strawberry - internal server error 500.

Вам бы лучше линукс попробовать. Реально меньше проблем будет.

На линуксе тоже все также тормозит. В Линуксе я не силен, потому пытаюсь отловить проблему на винде чтобы потом, возможно, починить это на линуксе.
Последний этап - отловил что при обращении к сайту сильно нагружается проц процессом Апача. в среднем от 35% и выше.
В итоге я вообще сломал весь сервак и теперь ни через ИИС ни через Апач ничего не работает. Буду откатываться на рабочий снапшот и пробовать советы Алексуса.

Как вариант - нам один раз дали под тест виртуалку, где ОТРС тормозил безбожно. Всё облазили, потом сделали тест на скорость чтения диска - 4 Мбит/с !!!!!. Оказалось, виртуалка стояла на каком-то сервере с замедленными винтами.

нагружается проц процессом Апача. в среднем от 35% и выше

Это обычное поведение Апача под Виндой. Надо делать под Юниксами.

Раньше я поднимал ОТРС на винде и тоже на апаче - таких проблем не было. странно.
Вот лог SQL бенча встроенного в ОТРС:

Multiplier 1*normal (ca. 25 stc)

Результат: SQL
КЛЮЧ ЗНАЧЕНИЕ ВРЕМЯ КОММЕНТАРИЙ
Insert Time: 10000 10 s Should not take more than 5's on an average system.
Update Time: 10000 11 s Should not take more than 9's on an average system.
Select Time: 10000 6 s Ok
Delete Time: 10000 9 s Should not take more than 5's on an average system.
Multiplier: * 1 s

Явный косяк со скоростью даже на первичном тесте....

журнал производительности.... некоторые пункты типа отправки почты обрабатывается ну очень долго... Понять не могу куда копать... все таки это проблема SQL или где-то еще руки кривые???

Диапазон (последние 1 день 0 час 0 минута)

ИНТЕРФЕЙС ЗАПРОСОВ МИНИМАЛЬНОЕ ВРЕМЯ ОТВЕТА МАКСИМАЛЬНОЕ ВРЕМЯ ОТВЕТА СРЕДНЕЕ ВРЕМЯ ОТВЕТА
Agent 72 0s 191s 18.45s
Admin 7 0s 30s 5.71s
AdminMailAccount 1 0s 0s 0s
AdminMailAccount;Ok=1 1 0s 0s 0s
AdminMailAccount;Subaction=Run;ID=2[...] 1 24s 24s 24s
AdminProcessManagement 1 13s 13s 13s
AdminSupport 1 15s 15s 15s
AdminSupport&BenchmarkSQL 1 36s 36s 36s
AdminSupport;Subaction=BenchmarkSQL[...] 1 0s 0s 0s
AdminSysConfig 1 2s 2s 2s
AdminSysConfig&SelectGroup 1 1s 1s 1s
AdminSysConfig;Subaction=Edit;SysCo[...] 1 2s 2s 2s
AgentDashboard 3 1s 1s 1s
AgentDashboard&Element 19 0s 111s 31.73s
AgentTicketAttachment;Subaction=HTM[...] 2 0s 0s 0s
AgentTicketAttachment;Subaction=HTM[...] 1 0s 0s 0s
AgentTicketAttachment;Subaction=HTM[...] 1 0s 0s 0s
AgentTicketAttachment;Subaction=HTM[...] 1 14s 14s 14s
AgentTicketAttachment;Subaction=HTM[...] 2 0s 1s 0.5s
AgentTicketAttachment;Subaction=HTM[...] 1 0s 0s 0s
AgentTicketAttachment;Subaction=HTM[...] 1 0s 0s 0s
AgentTicketCompose 2 103s 105s 104s
AgentTicketCompose&AJAXUpdate 1 44s 44s 44s
AgentTicketCompose&SendEmail 2 104s 191s 147.5s
AgentTicketLock;Subaction=Unlock;Ti[...] 1 0s 0s 0s
AgentTicketMove 1 1s 1s 1s
AgentTicketQueue 1 0s 0s 0s
AgentTicketQueue;QueueID=2;View=Small 1 1s 1s 1s
AgentTicketQueue;QueueID=6;View=Small 1 1s 1s 1s
AgentTicketQueue;QueueID=6;View=Small; 1 2s 2s 2s
AgentTicketZoom&MarkAsSeen 6 0s 2s 0.5s
AgentTicketZoom;TicketID=3119 2 1s 1s 1s
AgentTicketZoom;TicketID=3119;Artic[...] 1 0s 0s 0s
AgentTicketZoom;TicketID=3145 1 16s 16s 16s
AgentTicketZoom;TicketID=3461 2 0s 2s 1s
AgentTicketZoom;TicketID=3461;Artic[...] 1 0s 0s 0s

99,99% - проблемы с исходящей почтой! Соответственно все действия, связанные с отправкой уведомлений, вызывают адские тормоза. Потому что пока отправка почты не завершится, не "закрывается" действие.

Сервер почты на гугле и в общем и целом работает почта нормально. канала тоже хватает...
поможет ли перенастройка параметров почты?

1. Медленная система (диски?) по результатам SQL bench. На нормальном сервере должно быть 1-3 секунды для х1 теста
2. Проверяйте, как уходит почта, где рубится может быть на вашей инфраструктуре. У нас есть клиент с гугло-почтой - всё летает.

Сегодня утром цпу на виртуалке с отрс начало плющить, вместо привычных цпу 1-10%, 90-100%
По поиску вылетел на эту тему.
Совет с журналированием производительности помог. Там TicketZoom занимал 12 секунд, остальное по нулям.
Методом тыка нашли тикет в котором каждое письмо весило 500-600Кб, и в цепочке более 40 таких писем.
Вот если кто-то из сотрудников смотрел/отвечал в этом тикете, отрс плющило у всех других пользователей.