Евгений Русаченко

Если кому-то интересно, то информирую. В dmesg найдено было еще следующее:

[ 1803.199382] INFO: task mysqld:2318 blocked for more than 120 seconds.

[ 1803.199718]       Tainted: P           ---------------    2.6.32-531.29.2.lve1.3.11.5.el6.x86_64 #1

[ 1803.200379] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[ 1803.201029] mysqld        D ffff88080b653290     0  2318   1784    0 0x00000000

[ 1803.201031]  ffff8807dd0dfa88 0000000000000086 ffff8807dd0dfa50 ffffffff811e657f

[ 1803.201033]  ffff8806ba552040 000000000002abf0 ffff88002838f230 ffff880800000001

[ 1803.201035]  ffff88002838f220 ffff88080b653858 0000000100000000 000000000001dcc0

[ 1803.201037] Call Trace:

[ 1803.201040]  [<ffffffff811e657f>] ? __find_get_block_slow+0xaf/0x130

[ 1803.201044]  [<ffffffffa009d0a2>] start_this_handle+0x272/0x490 [jbd2]

[ 1803.201048]  [<ffffffff810a2120>] ? autoremove_wake_function+0x0/0x40

[ 1803.201053]  [<ffffffffa009d4a5>] jbd2_journal_start+0xb5/0x100 [jbd2]

[ 1803.201061]  [<ffffffffa00dfd16>] ext4_journal_start_sb+0x56/0xe0 [ext4]

[ 1803.201067]  [<ffffffffa00cceb7>] ext4_da_write_begin+0xa7/0x230 [ext4]

[ 1803.201071]  [<ffffffffa009c9b7>] ? jbd2_journal_stop+0x1e7/0x2b0 [jbd2]

[ 1803.201075]  [<ffffffff81135fdc>] generic_file_buffered_write_iter+0xec/0x290

[ 1803.201078]  [<ffffffff811dcc37>] ? __mark_inode_dirty+0x147/0x190

[ 1803.201082]  [<ffffffff81136ce5>] __generic_file_write_iter+0x225/0x420

[ 1803.201086]  [<ffffffff81136f65>] __generic_file_aio_write+0x85/0xa0

[ 1803.201090]  [<ffffffff81137019>] generic_file_aio_write+0x99/0x110

[ 1803.201093]  [<ffffffff8105b9a0>] ? __dequeue_entity+0x30/0x50

[ 1803.201098]  [<ffffffffa00c0008>] ext4_file_write+0x58/0x190 [ext4]

[ 1803.201102]  [<ffffffff811ad152>] do_sync_write+0xf2/0x140

[ 1803.201105]  [<ffffffff811ad438>] vfs_write+0xb8/0x1a0

[ 1803.201108]  [<ffffffff811adec2>] sys_pwrite64+0x82/0xa0

[ 1803.201112]  [<ffffffff8100b102>] system_call_fastpath+0x16/0x1b

Также было найдено, как можно было повесить MySQL. Стабильно зависал от: "mysqlcheck --repair --use-frm --all-databases"

Дальше стал копать, почему же ядро блокирует процесс на 2 минуты (в теории якобы из-за нехватки I/O, если не ошибаюсь, хотя iowait очень маленький, на сервере RAID 10 из 4 SSD).

Найдено было следующее, CloudLinux в Cpanel ставит странный init.d скрипт для MySQL, который ограничивает ресурсы для процесса. Скорее всего для db_governor из комплекта. Его замена на обычный init.d скрипт дала плоды - блокировок нет, mysqlcheck выполнился трижды без ошибок.

Всем спасибо за участие!

Но 2 в данном случае куда безопаснее 0. Ладно, тема не об этом. Пока что 2 сутки работает (тьфу-тьфу-тьфу).

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

Кроме PHP и MySQL ничем не прыгали, всё остальное стоит из коробки.

Убрать попробовать можно, попытка не пытка. Так как всё что можно было перепробовано уже.

innodb_flush_log_at_trx_commit на мой взгляд не безопасно. Хоть сервер стоит и в ДЦ, но никаких ИБП и RAID контроллера с батарейкой нет, чтобы такое ставить.

Исходя из письма Вы можете забрать резервные копии (если они делались через панель) через их тикеты. Цитирую:

По сути это сервер с огромным числом сайтов на Joomla, Drupal, WordPress и возможно чем-то самописным. MySQL строго настроен на использование 1/3 памяти сервера за пределы которого и не вылезает даже при 300 активных соединениях. По практике, если бы проблема была в запросах, то они просто бы тупили, но 1 запрос никак не мог бы вызывать очередь из 300 соединений и в какой-то степени положить MySQL.

---------- Добавлено 04.03.2015 в 16:09 ----------

Понятия не имею, за скрипты которые используются на сервере ответственности не несу и лезть мне в них нельзя. Моя задача только в том, чтобы сервер хорошо работал и эти скрипты хорошо работали.

Если где-то в статистике можно посмотреть число commit's, то ткните пальцем, посмотрю :)

---------- Добавлено 04.03.2015 в 16:20 ----------

MySQL собрался из исходников с официального сайта. MySQL 5.1 уже как-то слишком устарел на мой взгляд и 5.5 отлично работал и работает на CentOS 6.6, только не на этом сервере...

Подвисают именно InnoDB запросы, query_cache_size для них тоже используется? Всегда считал, что он только для MyISAM таблиц. Если да, то тогда попробую вовсе отключить, а не снижать. Если поможет - с меня какой-нибудь презент.

По skip-innodb-doublewrite ситуация такова. tmp папка вынесена в оперативную память и там O_DIRECT не работает корректно, лог заваливается ошибками:

В качестве аналога для O_DIRECT и включили skip-innodb-doublewrite.

Пробовали и без него тоже, это было добавлено недавно. Изначально, когда проблем еще не было, конфигурационный файл был еще куда проще:

[mysqld]

character-set-server=utf8

init-connect='SET NAMES utf8'

collation-server=utf8_general_ci



local-infile = 0

tmpdir = /dev/shm



# Буферы

sort_buffer_size = 4M

join_buffer_size = 4M

read_buffer_size = 4M

read_rnd_buffer_size = 4M



# Оптимизация производительности

key_buffer_size                 = 2G

tmp_table_size                  = 128M

max_heap_table_size             = 128M

query_cache_size                = 128M

max_connections                 = 300

max_user_connections            = 32



# InnoDB

innodb_log_file_size            = 128M

innodb_additional_mem_pool_size = 32M 

innodb_flush_log_at_trx_commit  = 2   

innodb_buffer_pool_size         = 4G  

innodb_file_per_table                 

Данный типовой конфиг стоит на десятках серверов и проблем нет. А на этом вот закрылась проблема. С этим конфигурационным файлом и опцией table_open_cache тоже происходит утечка памяти, с этого так скажем всё и начиналось. Опцию убрали, стали запросы вешаться в query end.

Лимит открытых файлов достаточно высок, в этом не может быть проблемы:

fs.file-max = 3275006

Для наглядности график соединений и памяти.

Ткну пальцем, так как видимо не уловили Ваше сообщение.

echo value > /proc/sys/dev/raid/speed_limit_min

Где value минимальная скорость в кб\с для синхронизации. Но учитывайте, что если поднять слишком высоко, система может начать сильно тупить.

У Вас именно в течение 4 лет убытки и нервы были? 😂 Вы видимо из тех клиентов, кто не делает резервные копии?

Ситуации бывают разные, в данном случае можно сказать у них отжали оборудование (если не ошибаюсь). Посмотрел бы я на Вас, будучи Вы владельцем компании, что бы Вы предприняли. Возврат средств? Сомневаюсь :)

Поэтому, я скажу так - данная компенсация, это лучше, чем ничего, поверьте. Компания свои ошибки поняла и приняла, выводы сделала. работают 5 лет без проблем.

Всем доброго дня.

Являюсь пострадавшим от 2010 года. Увидев данный топик, так скажем, написал наудачу Игорю Белову предоставив данные от аккаунта 2010 года. Не ожидал, но Игорь попросил зарегистрировать аккаунт на сайте их партнера vdsina.ru и зачислил средства на него.

С учетом того, что я до сих пор был зол на них - это вполне такой неплохой бонус от них.

А так, если смотреть в долгосрочной перспективе, то в течение можно сказать 5 лет у них проблем больше не было, можно потестировать vdsina.ru и если всё нормально задумываться уже и о приобретении услуг у mchost.ru