Здесь нельзя править сообщения старые. Таких тем много на данном форуме...
Понял, спасибо большое.
А что за работы были? По всей видимости они не всех коснулись, так как мне писем не приходило, сервера работали. Подозреваю, что либо это предстоит, либо и не затронет.
Смотря как настроить :) В нашем случае очень хороший прирост на всех серверах.
Вот в этом и вся прелесть. Если сервер настроен грамотно, то сайты не только будут кушать мало памяти, но и будут быстро работать. Например, на некоторых даже крупных хостингах я не встречал установленного xCache, Zend Opcache или чего-нибудь похожего. В итоге скорость работы сайтов падала за счет этого.
Если кому-то интересно, то информирую. В 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 сутки работает (тьфу-тьфу-тьфу).
Спасибо. Да, в OVH если для сервера включен мониторинг и он пропадает из сети сразу разбираются, но на сколько это хорошо работает - не знаю. Пока у них еще серьезно ничего не ломалось.
Спасибо!
У нас оборотов в миллионы нет, мы для них обычные клиенты. И скорее всего мы говорим о разных дата центрах.
Осталось железо в Online SAS, там за то время, что нас не было, немногое поменялось. В случае нестандартной ситуации выловить поддержку сложно.
Сам факт повышенного шанса повреждения базы данных не радует. Поэтому такое точно использовать не буду.
