Ця помилка часто помічається у користувачів віртуальної машини VMBitrix. Опишу суть проблеми. Попередньо на віртуальну машину розробники Bitrix встановили все необхідне основне, для роботи сайту, серед яких сервер баз даних MySQL. У процесах він іменується як mysqld (mysql daemon). Справа в тому, що в невизначений момент часу сервер просто падає (перестає працювати), після чого спроба запустити закінчується помилкою, з висновком такого повідомлення:

Another MySQL daemon already running with the same unix socket.
Starting mysqld: [FAILED]

Проблема в тому, що на віртуальній машині встановлена 32-х бітна Linux CentOS, яка має свої системні обмеження по ресурсах. Сам же сервер MySQL в своїх конфігураційних файлах має параметри розміру буферів, що перевищують системні обмеження.
Щоб стартанути сервер MySQL можна видалити файл mysqld.sock, з директорії /var/lib/mysqld/:

# rm /var/lib/mysqld/mysqld.sock
# service mysqld start

Однак це тимчасове рішення, тому що потрібно з цим щось робити. А можна зробити наступне. Перший варіант рішення: виставити обмеження розмірів буфера у файлі /etc/mysql/conf.d/bx/z_bx_custom.cnf.
На хабре є пост, в якому непогано описано параметри конфігурації, зокрема параметри розмірів буфера. Цитую.

Буфери

У всіх буферів є спільна риса — якщо через встановлення великого розміру буферу дані будуть йти в файл підкачки, то від буфера буде більше шкоди, ніж користі. Тому завжди орієнтуйтеся на доступний вам обсяг фізичної ОПЕРАТИВНОЇ пам’яті.

key_buffer_size — розмір буфера, що виділяється під індекси і доступного всім потокам. Дуже важливе налаштування, що впливає на продуктивність. Значення за замовчуванням 8 МБ, його однозначно варто збільшити. Рекомендується 15-30% від загального обсягу ОЗУ, проте немає сенсу встановлювати більше, ніж загальний розмір усіх .MYI файлів. Спостерігайте за змінними стану Key_reads і Key_read_requests, ставлення Key_reads/Key_read_requests повинно бути як можна менше (< 0,01). Якщо це відношення велике, то розмір буфера варто збільшити.
max_heap_table_size — максимальний допустимий розмір таблиці, що зберігається в пам’яті (типу MEMORY). Значення за замовчуванням 16 МБ, якщо ви не використовуєте MEMORY таблиць, то встановіть значення рівним tmp_table_size.

myisam_sort_buffer_size — розмір буфера, що виділяється MyISAM для сортування індексів при REPAIR TABLE або для створення індексів при CREATE INDEX, ALTER TABLE. Значення за замовчуванням 8 МБ, його варто збільшити аж до 30-40% ОЗП. Виграш в продуктивності відповідно буде тільки при виконанні вищезазначених запитів.

net_buffer_length — об’єм пам’яті, що виділяється для буфера з’єднання і для буфера результатів на кожен потік. Буфер з’єднання буде зазначеного розміру і буфер результатів буде такого ж розміру, тобто на кожен потік буде виділено подвійний розмір net_buffer_length. Вказане значення є початковим і при необхідності буфери будуть збільшуватися аж до max_allowed_packet. Розмір за замовчуванням 16 КБ. У разі обмеженої пам’яті або використання тільки невеликих запитів значення можна зменшити. У разі постійного використання великих запитів і достатнього обсягу пам’яті, значення варто збільшити до передбачуваного середнього розміру запиту.

read_buffer_size — кожен потік при послідовному скануванні таблиць виділяє зазначений обсяг пам’яті для кожної таблиці. Як показують тести, це значення не слід збільшувати. Розмір за замовчуванням 128 КБ, спробуйте збільшити його до 256 КБ, а потім до 512 КБ і поспостерігайте за швидкістю виконання запитів типу SELECT COUNT(*) FROM table WHERE expr LIKE a%»; на великих таблицях.

read_rnd_buffer_size — актуально для запитів з «ORDER BY», тобто для запитів, результат яких повинен бути відсортований і які звертаються до таблиці, що має індекси. Значення за замовчуванням 256 КБ, збільшіть його до 1 МБ або вище, якщо дозволяє пам’ять. Врахуйте, що вказане значення пам’яті також виділяється на кожний потік.

sort_buffer_size — кожен потік, що виробляє операції сортування (ORDER BY) або угрупування (GROUP BY), виділяє буфер зазначеного розміру. Значення за замовчуванням 2 МБ, якщо ви використовуєте зазначені типи запитів і якщо дозволяє пам’ять, то значення варто збільшити. Велике значення змінної стану Sort_merge_passes вказує на необхідність збільшення sort_buffer_size. Також варто перевірити швидкість виконання запитів виду SELECT * FROM table ORDER BY name DESC на великих таблицях, можливе збільшення буфера лише уповільнить роботу (в деяких тестах це так).

table_cache (table_open_cache з версії 5.1.3) — кількість кешованих відкритих таблиць для всіх потоків. Відкриття файлу таблиці може бути досить ресурсномісткою операцією, тому краще тримати відкриті таблиці в кеші. Слід врахувати, що кожна запис в цьому кеші використовує системний дескриптор, тому можливо доведеться збільшувати обмеження на кількість дескрипторів (ulimit). Значення за замовчуванням 64, його краще всього збільшити до загальної кількості таблиць, якщо їх кількість в допустимих рамках. Змінна стану Opened_tables дозволяє відстежувати кількість таблиць, відкритих в обхід кешу, бажано, щоб її значення було як можна нижче.

tmp_table_size — максимальний розмір пам’яті, виділеної для тимчасових таблиць, що створюються MySQL для своїх внутрішніх потреб. Це значення також обмежується змінної max_heap_table_size, тому в підсумку буде обрано мінімальне значення з max_heap_table_size і tmp_table_size, а інші тимчасові таблиці будуть створюватися на диску. Значення за замовчуванням залежить від системи, спробуйте встановити його рівним 32 МБ і поспостерігати за змінною стану Created_tmp_disk_tables, її значення повинно бути як можна менше.

Значення в конфігураційному файлі задаються в байтах, відповідно кілобайти і мегабайти потрібно переводити в байти.

Другий варіант розгорнути 64-х бітну Linux CentOS під веб-сервер, де системні обмеження значно вище в порівнянні з 32-х бітної. Цей варіант більш кращий, якщо ви хочете скористатися системними ресурсами сповна.

Додав: htmaker, 24.04.2014 р.
(Ще не оцінили)

Завантаження…

Діліться з друзями:

См. також:


Налаштування часу у VMBitrix
Рубрика: Bitrix, Linux

Видалення «кинутих» кошиків в системі Бітрікс
Рубрика: Bitrix

Використання highload-блоків в Bitrix
Рубрика: Bitrix

Як виконати SQL запит в Bitrix
Рубрика: Bitrix

Як підрахувати кількість елементів в Bitrix?
Рубрика: Bitrix

Динамічне масштабування зображень в Bitrix
Рубрика: Bitrix

Виключаємо користувача з ID=1 групи адміністраторів в Bitrix
Рубрика: Bitrix

Як скинути пароль адміністратора у Bitrix?
Рубрика: Bitrix

SQL-запити в бітрікс
Рубрика: Bitrix