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

  • Аватар

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

  • Аватар

Использование Vtiger CRM

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

Обсуждения функциональности, особенностей установки и настройки системы SalesPlatform Vtiger CRM.

У кого есть call-центр, поделитесь рабочим my.cnf (записей: 12)

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

    core i7, 16G RAM, Asterisk на другой машине
    В общем, намучался уже, Asterisk connector в пиковые моменты (30 входящих/исходящих) вешает систему, загружая весь проц на 100% (смотрю в htop). В остальные моменты система дышать может! У кого-то были похожие проблемы, поделитесь своим my.cnf, или посоветуйте по моему конфигу:

    character-set-server=utf8
    collation-server=utf8_general_ci
    init-connect=»SET NAMES utf8″

    bind-address=localhost
    skip-name-resolve
    max_connections = 250
    symbolic-links=0

    wait_timeout = 3600
    interactive_timeout = 3600

    join_buffer_size = 2M
    sort_buffer_size = 32M
    key_buffer_size = 192M

    read_buffer_size = 1M
    read_rnd_buffer_size = 2M

    query_cache_limit = 2M
    query_cache_size = 128M
    query_cache_type = 1

    thread_cache_size = 16

    tmp_table_size = 128M
    max_heap_table_size = 128M

    table_open_cache = 2048
    innodb_open_files = 2048

    innodb_buffer_pool_size = 8G
    innodb_buffer_pool_instances = 8
    innodb_flush_method = O_DIRECT
    innodb_flush_log_at_trx_commit = 2
    innodb_additional_mem_pool_size = 32M
    innodb_log_buffer_size = 8M
    innodb_read_io_threads = 8
    innodb_write_io_threads = 8

  • Аватар Алексей - 7 мес., 3 нед. назад:

    Так все-таки вешает asterisk connector или сама ЦРМ (процессы apache)? Просто коннектор никак не связан с mysql а использует sqlite, и если проблема действительно в нем, то конфиг мускуля тут ни при чем.

  • Аватар Иван - 7 мес., 3 нед. назад:

    Вешает сама ЦРМ, но при большом кол-ве звонков. Останавливаю Коннектор, система оживает! Правка my.cnf ухудшает производительность. Указанные выше параметры – наиболее оптимальные! Без коннектора могу их увеличивать (при необходимости) – и все работает стабильно! Потому и грешу на Коннектор, и пытаюсь найти еще более оптимальный конфиг мускуля! Повторюсь, это в пиковые моменты, но они и важны, в эти самые моменты работа как раз и кипит!
    Скрин htop – http://savepic.ru/13111739.png

  • Аватар Алексей - 7 мес., 3 нед. назад:

    Какая версия CRM вместе с сервис паком? И какое примерное число пользователей в CRM в пиковый момент, которые обрабатывают звонки?

  • Аватар Иван - 7 мес., 3 нед. назад:

    SalesPlatform Vtiger CRM 6.3.0-201507, 20 пользователей на телефонах, параллельно полноценно работают с остальными модулями ЦРМ (Контрагенты, Обращения, Заказы + вовсю работает CommerceML для обмена заказами с бухгалтерией).

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

    Что можно посоветовать:
    1. Обновиться хотя бы до 640, либо если не очень хочется этим заниматья, взять из 640 файл /modules/PBXManager/resources/PBXManagerJS.js и заменить в текущей системе, сделав бэкап. Там улучшена производительность за счет того, что запросы для получения звонков посылаются только из активной вкладки в барузере.

    2. Создать индексы по поисковым полям таблицы звонков (плохо что в родном не добавлены, а мы не перепроверили):
    CREATE INDEX vtiger_pbxmanager_user_idx ON vtiger_pbxmanager(user);
    CREATE INDEX vtiger_pbxmanager_callstatus_idx ON vtiger_pbxmanager(callstatus);
    CREATE INDEX vtiger_pbxmanager_direction_idx ON vtiger_pbxmanager(direction);

    Если хочется, то можно поиграться и с опциями создания индексов.

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

    1. Уже давно сделано – производительность улучшилась, но остались те самые пиковые моменты…
    2. Нужно попробовать…

  • Аватар Иван - 7 мес. назад:

    Замечено, процессор грузится на 100% в случае, когда все внутренние заняты, и звонок гуляет в очереди, отпинутый всеми статусом Занято! Так, для истории…

  • Аватар Виктор - 6 мес., 3 нед. назад:

    Сейчас не пользуюсь на SalesPlatform, ни Asterisk, но по представленным данным сделать выводы сложно, т.к. мало данных для профилирования.
    На представленном скриншоте все процессы – именно mysqld? Почему столько инстансов сервера? Он должен быть единственный.
    На том же скриншоте процессы не отсортированы по потреблению ЦПУ, Если проблема актуальна, обновите скриншот.

  • Аватар Иван - 6 мес., 3 нед. назад:

    Новый скрин – http://savepic.ru/13405170.png

  • Аватар Виктор - 6 мес., 3 нед. назад:

    Когда это будет возможным, остановите (все) mysqld. НО прежде предотвратите любое к ним обращение (чтобы не терять бизнес-данные), остановите всех, кто может обращаться к БД. mysqldump, если отработает нормально.
    Сперва `service mysql stop`, должен нормально завершиться тот процесс, чей pid записан в pid-файле. Проверьте, чтобы по завершении не осталось процесса `/bin/sh /usr/bin/mysqld_safe …`. Он убивается `pkill -9 mysqld_safe`. Затем методично завершайте все процессы mysqld.

    Если удастся всех завершить – `service mysql start`, смотреть лог и проверять консистентность БД (`mysqlcheck …`).
    Есть вероятность, что кто-то завершиться не сможет – там уже по обстоятельствам (и надежнее сходить на http://dba.stackexchange.com/)

  • Аватар Виктор - 6 мес., 3 нед. назад:

    И да, покажите вывод `mysqld –version` и, если удастся запустить нормально, – `ps ax | grep mysql`