вот то, о чем я говорю
steal time вылезает,

+ нужно смотреть latency дисковый, если выше 15ms, то привет жадные соседи или ребилд массива.

всё это надо не одномоментно смотреть, а чем-нибудь типа munin, zabbix или кто там ещё есть, копить и анализировать.

ЗЫ: тюнер всё правильно считает, он учитывает всю память, которую съедят все потоки, но гораздо раньше придёт радостный ООМ.

Там ничего интересного нет. В реальности всё ещё сложнее.

Я говорю про ту часть la, которая идёт от cpu. Занято всего 366.7%(php + mysql) из 400%, что даёт la в районе 3.5-3.7
Остальное -- это другие факторы, в частности вылезающий steal time, который может ощутимо подтормаживать виртуальные CPU и шедулер соответственно.
И большой la при неперегруженном до посинения cpu и wa 0.0 говорит о том, что гостевая ОС считает, что io нет, но по факту io очень большой, но на хосте, например, и гостевая ОС об этом ничего не знает и считает, что вся система просто сидит и ждёт у моря погоды.

Это типичное поведение, например, когда у дешевого хоста софт-рейд на обычных хардах ушел в пересчет чексумм. Либо соседняя машина жрет io по диску + cpu (смотрим steal time), либо хостовая нагрузка по сети (nfs какой-нибудь с бэкапами) и куча ещё всего, но снаружи гостя.

Это хорошо коррелирует с ситуацией, когда у ТС la падает до 3.5 внезапно, т.к. реального io внутри виртуалки мизер(иначе wa был бы 0.1 хотя бы, hi и si тоже по нулям), а cpu занят как раз пхп и мускулем. Да cpu близко к перегрузу, но это уже другой вопрос. Там какой-нибудь opcache, переход на fcgi или оптимизация алгоритмов могут помочь.

Чтобы реально и вовремя диагностировать всю эту ботву, нужен нормально настроенный мониторинг.