Антон Полягин (Все сообщения пользователя)

Когда выйдет стабильная после 7.4.11? Установил... и пошли лютые тормоза  

Mysql упрямо отъедает всю оперативную память сервера и система уходит в swap. Есть два портала на 100 и 50 пользователей. Оба портала в полном стоке т.к. никакие параметры и конфиги не менялись, все окружение полностью bitrixVM везде последнии стабильныее версии и окружения и порталов. Портал на 100 пользователей имеет 20гб оперативной памяти и уходит в свап через неделю. Портал на 50 пользователей имеет 48гб оперативной памяти и тоже уходит в свап через через неделю. Вопрос как этим бороться? Ограничивать mysql через z_bx_custom.cnf?
Вот что сейчас в bvat. Собственно я уже и так уменьшил придел перехода в swap и указал что использовать его можно только по достижения 1% свободного остатка от объема памяти. т.е. если остается только 650 свободно то система уходит в свап и уходит стабильно причем на 10-20мб всего.


сервер с 20гб оперативной памяти выделенными для виртуалки:

# memory: 24576MB
[mysqld] - z_bx_custom.cnf (чуть чуть модифицирован для очистки грязных записей до перезагрузки)
   query_cache_type = 1
   query_cache_size = 128M
   query_cache_limit = 16M
   innodb_buffer_pool_size = 10240M
   max_connections = 60
   table_open_cache = 18432
   thread_cache_size = 512
   max_heap_table_size = 128M
   tmp_table_size = 128M
   key_buffer_size = 256M
   join_buffer_size = 32M
   sort_buffer_size = 32M
   bulk_insert_buffer_size = 2M
   myisam_sort_buffer_size = 32M
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

[root@bitrixcrm ~]# free -h
             total        used        free      shared  buff/cache   available
Mem:      20G         12G        258M        2.0G        8.6G        6.5G
Swap:    511M        7.3M        504M



сервер с 48гб оперативной памяти выделенными для виртуалки:
# memory: 65536MB
[mysqld] - bvat.cnf
   query_cache_type = 1
   query_cache_size = 128M
   query_cache_limit = 16M
   innodb_buffer_pool_size = 18432M
   max_connections = 205
   table_open_cache = 18432
   thread_cache_size = 512
   max_heap_table_size = 128M
   tmp_table_size = 128M
   key_buffer_size = 256M
   join_buffer_size = 32M
   sort_buffer_size = 32M
   bulk_insert_buffer_size = 2M
   myisam_sort_buffer_size = 32M

[root@crm ~]# free -h
             total        used        free      shared  buff/cache   available
Mem:      48G         25G        349M        2.9G         22G         19G
Swap:     511M          0B        511M


Что делаю не так? help!

У тебя кончилось место на диске вероятнее всего, база соответственно не стартует. Зайди по sftp и удали созданные бэкапы или вытащи их а потом удали.. После сделать в консоли service mysqld start

Судя по всему вы не знаете во что залезли.. это не конструктор сайтов а полноценная платформа. Как минимум нужно понимать что и как работает ну или хотя бы зачем.  

Коллеги, кто-то что-то с этим смог придумать? Столкнулся с этой же проблемой.

Дмитрий Кошелев, нужно открыть порты (лучше если без прокси):

25 bitrix smtp сервер

80 http

443 https

22 SSH

5222 bitrix xmpp сервер

5223 bitrix xmpp сервер по ssl

5060 bitrix voximplant

8890 ntlm авторизация

8891 ntlm авторизация ssl

8893 push & pull

8894 push & pull ssl

После поставить SSL сертификат т.к. без него половина работать не будет.

У поддержки на всё ответ.. - переустановить окружение.  

проблема в чем-то другом.. всё работало и домен присвоен в хосте, всё работает с сертификатом в штатном режиме, но в проверке лезет ошибка упорно.

Присоединяюсь, последнее обновление сломало это..

Добрый день, коллеги! Есть ли у кого-то опыт обязательных полей для открытых линий? Чтобы нельзя было начать чат не указав номер телефона?
У нас сфера разовых продаж, и нам обязательно нужно собирать контакты для консультации.. Столкнулись с тем что в открытых линиях нельзя сделать обязательным контакты для онлайн-чата.
Может кто-то сталкивался с этим?  Возможно ли как-то кастомизировать?

Кто-то знает кк вот это остановить? http://joxi.ru/1A51N66fD59X0A Бесконечно продолжается.. и в лидах и в сделках. Причем длиться по неделе.  

Проблема оказалась вот в чём.... обновление подключило APC и оно видимо работало криво. Рубанул его и всё вернулось на круги своя.  

Вот это упорно лезет в лог

2019-08-06T11:42:40.130828Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.130890Z 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.130900Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131016Z 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131027Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131086Z 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131096Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131142Z 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131152Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131194Z 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131214Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131257Z 0 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2019-08-06T11:42:40.131267Z 0 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade

После обновления 7.4-1 портал стал жутко тормозить. Сначала решил что включился опять xdebag, проверил... нет оно отключено. Стал смотреть логи, в них тоже ничего нет сверхъестественного. Тормозит база явно БД, все операции с ней тупо зависают и производятся очень медленно. Например смена ответственного за 30-50 задач может затянуться на 2-3 часа или зависнуть наглухо.  По производительности также видно:

База данных MySQL (запись) 1 331 5 600 количество запросов на запись в секунду База данных MySQL (чтение) 15 206 7 800 количество запросов на чтение в секунду База данных MySQL (изменение) 7 186 5 800 количество запросов на изменение в секунду

При этом распределение ресурсов делалось самой системой т.к. кастомный файл z_bx_custom отключен.
файл тюнера mysql http://joxi.ru/a2XDdPPiwzbl12
В проверке системы ошибок нет, всё работает но ооочень медленно.
Всего на портале 68 пользователей, работает одновременно 40-50.

Может кто-то сталкивался с этой проблемой после обновления? Куда копать?

У меня он тоже пустой, но когда в конце расширение ini.dusabled не прописано работает отладка. Попробуйте дописать и перезагрузить сервер.  

и? Я это и так знаю.. речь идёт о том что есть сотрудники с правом выгрузки, и нужно понимать что они выгружают из  системы. Предположим есть ситуация.. когда сотрудник из выгрузок формирует отчеты, у него есть правок на выгрузку определенных сделок а он взял и выгрузил все сделки. Необходимо понять какие поля он выгрузил и для чего.. сейчас это никак получается понять нельзя.

Выгрузил сделки в xls , поправил поля руками, ну написал комментарии..
Хочу загрузить обратно чтобы обновить комментарий.
Вместо обновления текущей сделки (в файле есть все данные сделки включая id) создаётся новая сделка и привязывается к существующему контакту.
Это так и должно быть? Кто-то сталкивался с этим?

Ну факт понятно.. и этот факт выгрузить нельзя как сказала поддержка. Уровень безопасности получается у системы нулевой.. абсолютно.
Если например я хочу проанализировать какие сотрудники с правом выгрузки что выгружали то кроме как 500тыс. записей я ничего не увижу. Как то это абсурдно.. Файл сохраняется в кеше как я увидел но почему то нашел не все файлы, а только за день текущий, видимо старые файлу удалются если чистить кэш ручками.

Никто не сталкивался с этим?

Нужно понять, где лежат файлы экспорта лидов/сделок/компаний/контактов из CRM, естественно в коробке.
Как выгрузить историю CRM?
Цель проанализировать кто, что и когда выгружал.  

Михаил Белов, у меня такое было когда был включён xdebug, проверь, может после поддержки не отключили.

Спасибо больше Вам! Два три админа и два программиста не смогли разобраться! Вот единственный вопрос  как это могло сломаться? После трабла с правами прошло больше месяца, машина работала и много раз полностью перезагружалась о_0  

Неужели решения нету?

multiktvs,удалось решить?