Александр Пащенко, Если у вас много оперативки и нет гиганстких массивов данных, из быстрых решений могу посоветовать часто используемые таблицы подменять временными таблицами. Но тогда придется вручную запускать синхронизацию и существует вероятность потери последней информации. - Например, статистику посещений, скажем, за последние 15 мин потерять не жалко. Ну и вообще смотреть на критичность тех или иных данных. Временные таблицы хранят данные в оперативке, почти не нагружают io, не напрягают чтением/записью ваш raid. Это самый простой сисадминский шаг, то есть в коде пыха ничего менять не придется.
Блокировки возможны, и даже наверняка сильно тормозят дело. Но навряд ли именно они - причина такого странного поведения мускуля.
Что именно кажется странным? Я почти уверен, mysql проц жрет именно организация очереди. Через какие-то промежутки mysql сбрасывает соединения как зависшие, это дает вздохнуть хоть немного idle процу сервера, но если проект под нагрузкой, все повторится...
Александр Пащенко, myisam работает архибыстро т.к. в myisam не вносили архитектурных изменений со времен популярности (и актуальности) mysql3. На тот момент mysql3 пользовались для своих расчетов даже NASA.
InnoDB конечно хороша, и даже уже стабильна. Но, когда сжатый gz-файл таблицы весит >16Gb, а примитивный key-индекс >500Mb, innodb делает примитивный SELECT одной записи по ключу около 10сек, без ключа по точному совпадению каждого символа в строке >4 мин. myisam с поиском по строке без индекса справляется за 1.7сек. В тестах использовал таблицу состоящуюю из трех полей: id, url, name. Данные - каждая строка содержит соответствующую информацию определенного пользователя вконтакта. Не смотря на то, что таблица содержит текстовые данные, строки заданы фиксированным размером. Даже если обявить индексы по всем полям, myisam добаляет >10к записей в секунду (с ростом БД скорость падает незначительно), innodb под конец теста добавлял одну запись за ~30сек.
Никита Полевой: Кстати, не удивлюсь, если лет через 5 новоиспеченные программеры ноды не будут знать как использовать коллбеки, и, собственно, не будут подозревать что косьвенно используют их. - Для этого осталось чуть перелопатить официальную документацию, убрать унылые примеры с колбаками, сделать все примеры с async/await. Ведь были времена до промисов и бабели, когда модули async и Q были в топе npm. Сам лично использовал async.waterfall() в каждом проекте. На тот момент они имели статус мастхэв. Без них борьба с лапшлой была возможна только с использованием EventEmitter. - Но с EventEmitter-ом код становился в два раза непонятнее по сравнению с последовательной лестницей из колбаков.
Никита Полевой: Блин, я немного неверно выразился. Не рекурсивно, но многоуровнево с заданной максимальной глубиной. Разумеется, рекурсивно можно обойтись и без for await, но вечер долгий, можно попытаться примастырить и его, хотя почти уверен, что от рекурсивной функции избавиться с помощью него не получится. :-)
Iceman77: Боже, спаси и сохрани! Никогда бы не осквернил такой божественный компьютер Мелкомягкими Окнами. Посмотрите - видео от Intel - да у них есть опенсурсные драйверы, можно собрать под любую ос. Тут же есть модный Thunderbolt™ 3, которым я никогда не пользовался! Чем вам не миник?
Кстати, очень напрасно. Бывает, решением всех бед с производительностью может являться создание простого индекса из двух полей.