[lxa85]

evpu, вы уверены, что ваш тест корректен?
Кроме самого запроса, его можно оптимизировать как "руками", так и средствами MySQL (план выполнения запроса).
Если прям так надо, вытаскивайте таблицу в виртуальную.

что можно оптимизировать в этой ситуации »

Структуру БД, в частности провести индексацию полей.
Посмотреть, какая подсистема (банально жесткий диск) стопорит работу системы.
Посмотреть, насколько эффективно настроена работа с ОЗУ (пальцем в небо).
Опять же, если углубляться, должны существовать системы нагрузочного тестирования, которые формируют подробный отчет о слабостях установки. Это будет более весомо для начальства, более подробно для вас, и разумеется более корректно, чем банальная множественная выборка.

Малость гугления
sysbench
hp loadrunner
jmeter

[evpu]

Спасибо, изучим.

Ну, пока проблему решили брутально - переносом системы на SSD и кардинальной сменой конфигурации сервера.
С core2duo на i5, и памятью с 1ГБ ДДР2 на 8ГБ ДДР3. Debian 8.1 без ничего лишнего... Только мое ядро ПО, LAMP, и админский минимум.

В дальнейшем хочу создать зеркалирующий RAID из нескольких SSD только под хранение базы, а сама система на другом SSD.

Т.е достаточно тупо в плане оценки причины, но освободился старый сервак, можно будет экспериментировать.

С тех пор нагрузка возросла еще вдвое, тормоза как в ноль ушли так там пока и остались.

[evpu]

Нагрузка возросла еще вчетверо, снова пошли замедления... присмотрелся к базе - некоторые поля почему-то имели тип varchar хотя логичнее было бы integer. Поменял - опять было приятно отнаблюдать, как время ответа ушло почти в ноль...


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

Вопрос такой - если основательно наговнокодить, с эффектом - целый шквал запросов будет пытаться ломануться на неоткрытое соединение (ну не открылось оно... или забыл открыть) - это я про MySQL - может ли быть такое, что в результате этот коннектор затупит настолько, что продолжит ужасающе глючить после отработки указанного шквала запросов?

Т.е есть приложение (опишу позже) - оно fork-ом генерирует пару десятков дочерних потоков. В какой-то момент, один из потоков вдруг выдает резко пару десятков попыток запросов без открытия соединения, и как эффект - это ложит все 30 потоков, но не начисто, а где-то наполовину. Приложение работает, но часть данных теряется. Помогает банальный перезапуск приложения.

Зарезал генерацию этого конкретного потока - там были обособленные по смыслу специфические процедуры - все исчезло начисто.

Непонятно, в упор... это же в отдельном потоке.
Даже если бы я пытался там отработать полнейший говнокод - неужели один поток может заставить устойчиво погнать целый коннектор?

[itkrondotcom]

Суть понял, только вот как проделать оптимизацию это вопрос