Высокий iowait

Поставили ещё 8гб озу, ситуация стала немного получше, но странно что ссд никак не изменил ситуацию. Т.е даже при недостатке памяти ускорение диска должно было уменьшить ва. Может это что-то с контроллером или опять же из-за прослойки.

tuning-primer ничего нового не сказал

askary а все данные не влезают на этот SSD?

на последних картинках видно, что SSD добавили только для mysql. Но ведь никто не говорил, что дело только лишь в mysql.

Так ssd то sdb? У него вон под mysql утилизация 0%, а sda всё так же занят, значит другое что-то.

Ну а по i/o на sda, там записи 16%, если среднесуточно всё так же, можно сделать кэш на ssd без writeback.

---------- Добавлено 06.08.2014 в 17:48 ----------

upd. опередили.

Оставили 16гиг, %ва упал в несколько раз и даже не подскакивает при нагрузках.

, сервер свопился?

WapGraf, да не обязательно, как видно, там чтения на порядок больше, вот в pagecache часть i/o и попала.

esetnod, опять предположение, как и у меня. Данных по потреблению оперативной памяти приложениями нету, данных по использованию swap нету.

---------- Добавлено 06.08.2014 в 21:47 ----------

Это не основная ваша проблема, если вообще проблема. По sdb нагрузки нету совсем.

Еще надо не забывать, что /tmp, tmpdir от MySQL и папка кэша Nginx'а остались на Sata (а с учетом добавки памяти можно попробовать для них tmpfs).

2All: "WordPress and Drupal Denial Of Service Vulnerability Full Disclosure": http://www.breaksec.com/?p=6362

вот. судя с графиков, особо потребление памяти не выросло, хотя своп не используется уже вообще. не знаю, в объеме памяти ли была проблема(возможно top контейнера не полную картину показывает), но вроде все ок. тьху-тьху-тьху