Web-приложение работает под Linux с гигантскими таблицами MyISAM (этот движек используем ради производительности), использует unbuffered-чтение.
В условия загрузки CPU сервера сторонним процессом (архивацией бекапов) сталкиваюсь с проблемой, подобной описанной здесь:
http://stackoverflow.com/questions/3780521/strange-mysql-error-empty-row-packet-body-when-using-mysql-fetch-object-php-5
Там рекомендуют увеличить значение глобальной переменной СУБД table_lock_wait_timeout, однако её убрали из новых версий как MariaDB так и MySQL.
Что делать?

Здравствуйте, shestero, Вы писали:

S>Web-приложение работает под Linux с гигантскими таблицами MyISAM (этот движек используем ради производительности), использует unbuffered-чтение.
S>В условия загрузки CPU сервера сторонним процессом (архивацией бекапов) сталкиваюсь с проблемой, подобной описанной здесь:
S>http://stackoverflow.com/questions/3780521/strange-mysql-error-empty-row-packet-body-when-using-mysql-fetch-object-php-5
S>Там рекомендуют увеличить значение глобальной переменной СУБД table_lock_wait_timeout, однако её убрали из новых версий как MariaDB так и MySQL.
S>Что делать?

S>движек
S>движЕк
S>ееее
S>ёёёё
S>MyISAM ради производительности
S>MyISAM ради производительности
S>движЕк
S>движЕк ради производительности
S>Что делать?

А разгадка одна...

Запускать архивацию через nice 9, чтобы уменьшить приоритет процесса архивации.

Здравствуйте, shestero, Вы писали:

s> Web-приложение работает под Linux с гигантскими таблицами MyISAM (этот движек используем ради производительности)

Спорное решение особенно для гигантских таблиц.

s> В условия загрузки CPU сервера сторонним процессом (архивацией бекапов) сталкиваюсь с проблемой Что делать?

Бэкапиться с реплики.

AB>Спорное решение особенно для гигантских таблиц.
Я не вижу аналогов даже рядом по производительности!
Подскажешь? Запросы — простые выборки.
На днях смотрел Aria, но лишена ли она этой самой проблемы??

MyISAM ещё очень удобен тем, что в случае аварии таблицы изборочно можно максимально быстро перебрасывать как файлы на другой сервер.

PS Не в этом суть чем именно грузится CPU — архивацией или чем-либо другим. Загрузка может возникнуть и из-за штатной одновременной работы нескольких пользователей.

PS NB оказывается в добавок в PHP имеется баг, из-за которого там неверно обрабатывается этот сбой в СУБД при работе через MySQLi: https://bugs.php.net/bug.php?id=66370

Здравствуйте, shestero, Вы писали:

S>Web-приложение работает под Linux с гигантскими таблицами MyISAM (этот движек используем ради производительности), использует unbuffered-чтение.
S>В условия загрузки CPU сервера сторонним процессом (архивацией бекапов) сталкиваюсь с проблемой, подобной описанной здесь:
S>http://stackoverflow.com/questions/3780521/strange-mysql-error-empty-row-packet-body-when-using-mysql-fetch-object-php-5
S>Там рекомендуют увеличить значение глобальной переменной СУБД table_lock_wait_timeout, однако её убрали из новых версий как MariaDB так и MySQL.
S>Что делать?

производительность ISAM — это да но ISAM он одно поточный. бэкап — увы второй поток. все должно мёрзнуть по дизайну.

12.12.2016 20:16, shestero пишет:

> AB>Спорное решение особенно для гигантских таблиц.
> Я не вижу аналогов даже рядом по производительности!
> Подскажешь? Запросы — простые выборки.

Давно отказались от MyISAM и используем InnoDB (сборка MySQL от Percona)
— работает отлично в т.ч. на довольно больших таблицах (настройки,
естественно, тюнили). Наибольший размер таблицы у нас около 250М записей.

--
WBR,
Serge.

Здравствуйте, shestero, Вы писали:

S>Web-приложение работает под Linux с гигантскими таблицами MyISAM (этот движек используем ради производительности), использует unbuffered-чтение.

MyISAM не имеет своего кэша данных. Может кэшировать только индексы.
InnoDB , наоборот, это умеет делать, и делает хорошо (innodb_buffer_pool_size).