Производительность MYSQL-2
 

Добрый день!

Суть такая. (уже писал) - создано приложение на С, крутится на Debian, с использованием коннектора mysql. Все бы хорошо, но начал замечать одну вещь - при значительном нарастании количества одновременных соединений начинает притормаживать база, причем разумеется не вся, а таблица к которой идет наибольшее количество обращений, и как следствие остального.

Для теста провожу много раз простейший запрос.

SELECT * FROM `data` WHERE `hexkey` = '0010005D04FB'

Вот время ответа:
0.0006
0.0048
0.1391
0.0005
5.1097
0.0005
0.6763

А оно между тем живет своей жизнью, естественно, попадаются моменты пиковой нагрузки. параметр max_connections выставлен в 5000.

Хотя целиком комп живет на core2duo и 1 ГБ ОЗУ, перед безусловно обязательным мероприятием - заменой сервера на XEON и т.д очень бы хотелось разобраться - что можно оптимизировать в этой ситуации.

на Хабре и в Гугле достаточно всякого на эту тему, но может, кто конкретно знает куда копать?

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

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

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

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

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

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

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

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


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

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

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

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

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

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