Администраторы группы

  • Аватар

Модераторы группы

  • Аватар

Интеграция Vtiger CRM

Открытая группа активность: 2 нед., 4 дн. назад

Обсуждаем вопросы использования интеграции SalesPlatform Vtiger CRM с другими системами: Asterisk, 1С и др., а также использование Клиентского портала.

Процесс mysqld грузит все ядра CPU 100% [РЕШЕНО] (записей: 9)

← Форум группы   Все форумы
  • Аватар kosb - 3 г., 12 мес. назад:

    SalesPlatform 6.1.0, MySQL 5.1
    Количество активных пользователей CRM порядка 30 человек.
    Наблюдаем загрузку всех 8 ядер процессора в пиковые моменты 100% длительностью до 5 сек.

    my.cnf заменили на my-huge.cnf
    +innodb_buffer_pool_size = 384M
    +innodb_additional_mem_pool_size = 20M

    Изменений нет.
    1) Если кто-то сталкивался, удалось ли решить и как?
    2) Если кол-во пользователей ~30 то какие версии платформы и базы используются?
    3) Содержимое my.cnf ?

  • Аватар Дмитрий - 3 г., 11 мес. назад:

    Странно, что у Вас аж 8-ми ядерный процессор нагружается MySQL до 100%. Там только одна БД Salesplatform содержится?

    Замените MySQL 5.1 на MariaDB 5.5.x или 10.0.x (см. https://downloads.mariadb.org/). Можно также посмотреть в сторону Percona Server (см. https://www.percona.com/software/percona-server). Совсем кратко о них можно прочитать здесь http://habrahabr.ru/post/108104/
    Обновление происходит легко – новый SQL-сервер просто ставится поверх имеющегося с заменой.

    Далее, убедитесь, что все таблицы БД данной CRM работают в InnoDB.

    Потом было бы неплохо сделать резервную копию БД, удалить её, создать заново и загрузить обратно файлы. Это нужно, чтобы избавиться от единого большого файла ibdata, хранящего все таблицы БД. В новых версиях MySQL (и других его клонов) изначально установлен параметр innodb_file_per_table = on, заставляющий SQL-сервер хранить каждую таблицу в отдельном файле.

    Ну и напоследок могу лишь предложить запустить mysqltuner.pl и посмотреть его рекомендации.

  • Аватар Алексей Зозуля - 3 г., 11 мес. назад:

    @kosb как минимум слишком маленький innodb_buffer_pool_size.

    Должно помочь:
    См. статьи: http://habrahabr.ru/post/66684/ , http://habrahabr.ru/post/108418/ , http://ruhighload.com/index.php/2009/04/23/%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-mysql-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0/

    Ключевые параметры: innodb_buffer_pool_size, innodb_lock_wait_timeout, innodb_log_file_size, innodb_flush_log_at_trx_commit, innodb_thread_concurrency=8 (вывод текущих настроек: mysql> SHOW VARIABLES)

    Также м.б. полезно для анализа конфигурации – http://mysqltuner.com

  • Аватар kosb - 3 г., 11 мес. назад:

    Принято.

  • Аватар Игорь - 2 г., 10 мес. назад:

    похожая ситуация, но мне не помогло. сначала переезали на сервер с 2 ядрами по 3.2 и 8 гб памяти, там крутилась тигра 6.4 и астериск с коннектором. база – mariaDB5.5 , innodb buffer – 6G, file per table -on, и все плюшки по ркекомендациям стояли. нифига не помогает, один хрен 100%. перенес базу на мощный сервер с 8 ядерным xeon и 64 GB памяти(там уже percona 5.5 поставил) – работать работает, но mysql скачет под 400% нагрузки, и mysql-трафика за день уходит около 11 GB. только на vtiger, а там всего лишь 20 человек колл центр. записей в таблицах не очень много, база весит 300 МБ(sql-дамп). уже и не знаю че ей придумать, может у кого идеи есть. по рекомендациям mysqltuner довел базу до состояния «менеджер не может войти в црм», откатил все взад, ничерта не помогает.

  • Аватар vladimir - 2 г., 9 мес. назад:

    Была такая же беда. И тоже кучу мануала по mysql перелапатил. Победил. Дело было в порте конектора. На момент сборки порт был один а через тримесяца что то мне порт не понравился и я решил его изменить вот тут и понеслось тигр ложил двухпроцессорный серва xeon 5620 напроч. Так что попробуйте.

  • Аватар Андрей - 1 мес., 2 нед. назад:

    У меня та же история, Vtiger CRM 7.1.0-201803, MariaDB 10.1.26 грузит CPU вот такими запросами:

    SELECT * FROM vtiger_pbxmanager AS module_table INNER JOIN vtiger_crmentity AS entity_table WHERE module_table.callstatus IN(‘ringing’,'in-progress’) AND module_table.direction=’inbound’ AND module_table.pbxmanagerid=entity_table.crmid AND entity_table.deleted=0

    Запросы запускаются с периодичностью где-то в 10-15 секунд, по 10-12 запросов одновременно, и если я что-нибудь в чём-нибудь понимаю, то это всплывающие уведомления о звонках. Количество одновременно запускающихся запросов примерно соответствует количеству залогиненных пользователей.
    В таблице vtiger_pbxmanager сейчас около 230 000 записей, 6 ядер E5-2420 не хватает, во время запуска каждой пачки запросов интерфейс задумывается на 5-10 секунд. Тюнинг параметров innodb почти никак не повлиял на ситуацию, всё так же тормозит.

  • Аватар Станислав - 1 мес., 2 нед. назад:

    Андрей (@detuner), проблема решается добавлением индексов. Подробная инструкция в теме по ссылке:
    https://community.salesplatform.ru/groups/vtiger-crm/forum/topic/%D0%BC%D0%B5%D0%B4%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D1%8B-sql/

  • Аватар Андрей - 1 мес., 2 нед. назад:

    Станислав, большое спасибо, это помогло.