увеличение кол-ва доступных php-fpm лишь немного отодвигает момент падения.
Из-за чего происходит падение? И что падает?
При недостатке воркеров задачи должны становиться в очередь.
Если тупо в лоб решать, fpm воркеров вам нужно не бесконечно много, а ровно столько, чтобы компенсировать лаг ответа. Если они ничего не делают, почему бы их не сделать много ровно в том пуле что отвечает за долгие запросы. Упираетесь в память?
Если обобщить, fpm процесс кладёт задание в очередь. По мере обработки очереди ответ поступает на фронт.
Конкретная реализация зависит от ваших хотелок. Очередь в бд или в брокере. Polling на фронте или websocket.
Обработку очереди лучше сделать асинхронно, иначе опять наплодите процессы в ожидании.
Dimonchik, похоже вы правы, во-первых перекидывание данных между движками бесплатное - хз почему, во-вторых инсерты в InnoDB на порядок медленнней чем в MyISAM. Получается схема реально будет быстрее. Не пробовал загрузчиком из csv, но не думаю, что там будет чтото разительно другое.
На 4M коротких строчках, только pk ничего более (MySQL 5.7):
-- из MyIsam в InnoDb - 16s
-- из InnoDb в InnoDb - 19s
-- из InnoDb в MyIsam - 11s
-- inserts из файла в MyIsam - 5m41s (имеется ввиду mysql < file.sql)
-- inserts из файла в InnoDb - ~54m (через 27m на 50% я задолбался ждать)
Причем неважно как данные перебрасывать alter engine или insert select, время тоже. При повторном тесте, примерно те же самые результаты.
Спасибо большое, очень интересная штука. Есть над чем подумать.
mayton2019, да, в CBO делают прямо настраиваемые параметры стоимости чтения страниц с диска. Но сейчас много, если не большинство, систем где упор делается на работу в оперативной памяти, и соответственно расчеты СВО должны быть другие, но я без понятия, как он учитывает загружена страница в память или нет.
mayton2019, попробовал на MySQL, просто несколько запросов, особо не заморачивался. При выборке по pk, он всегда идет по pk. При выборке по некластеризованному неуникальному индексу, он также идет по нему, но если в таблице уже не 1 строчка (то 4, то 8, причем не вижу связи с длиной) он делает full scan, если % нужных строк падает примерно до 30 он возвращается к индексу.
Вероятнее всего, когда мы делаем full scan нам все равно нужно найти 1 страницу, а ее логично получать по pk, поэтому для единственного значения дешевле всегда идти по pk. Для неуникального индекса сложнее, хз как он расчитывает стоимость, но ради единственной строки он предпочтет индекс. Но это все в MySQL.
ubirust, блин, т.е. это нормально...
На что накладываются ограничения? Исходя из этого, уже можно искать решение. Если СУБД медленно жует отдельные запросы - отправляйте батчем, т.е. вместо:
INSERT INTO `orders` VALUES (что нужно вставить);
INSERT INTO `orders` VALUES (что нужно вставить);
INSERT INTO `orders` VALUES (что нужно вставить);
чтото вроде этого:
INSERT INTO `orders` VALUES (что нужно вставить),(что нужно вставить),(что нужно вставить);
Dimonchik, скорее всего медленней чем readfromfile в MyISAM. Но, быстрее, чем залить сперва в MyISAM, а потом перекидывать все в InnoDB. Либо я чтото не понимаю в этой хитрой схеме...
ubirust, просто 5 вставок в секунду, это прям настолько мало, что дело не в настройках СУБД (если они дефолтные, конечно), не в заливки из csv т.п. Может у вам уже диск отказывает?
Заливка из файла разумеется быстрее.
Но "MyISAM потом замена на innodb"? Вы как считаете время? До момента когда все данные будут доступны в InnoDB или только заливка в MyISAM?
MyISAM и InnoDB по-сути разные СУБД, поэтому при смене движка, понадобится данные забрать из MyISAM загрузить его на уровень MySQL, потом залить в InnoDB, это гораздо медленней, чем пересоздание таблицы внутри движка. Поэтому я не понимаю, как такое может быть быстрее.
И, кстати, да, если вы выделили под buffer pool 1G, не стоит удивляться что СУБД будет использовать этот 1G. Вопрос, что же она там наразмещает интересный, но уже теоретический.
yapaofficial, типа такого, он отправит только конкретному клиенту, от которого пришло сообщение.
Кстати, попробовать и убедиться у вас заняло бы 5 минут.
К слову о maxmind, локальный поиск будет явно в разы быстрее. Не говоря уже о стабильности. Подключить maxmind это те же 10 строчек. Обновление 2 раза в неделю, и для автоматического обновления они предоставляют готовый скрипт.
Единственное, если нужна халява, я не помню, чтобы у них была бесплатная версия.
Из-за чего происходит падение? И что падает?
При недостатке воркеров задачи должны становиться в очередь.
Если тупо в лоб решать, fpm воркеров вам нужно не бесконечно много, а ровно столько, чтобы компенсировать лаг ответа. Если они ничего не делают, почему бы их не сделать много ровно в том пуле что отвечает за долгие запросы. Упираетесь в память?