В разделе администратора сайта клиента есть действие, скажем, Admin::Analytics (которое я не создавал, но должен поддерживать), которое компилирует аналитику использования сайта, выполняя пару десятков довольно интенсивных запросов к базе данных. Эта функциональность всегда была узким местом для производительности приложения при составлении аналитического отчета. Но в последнее время узкое место стало настолько серьезным, что при доступе к сайту он резко останавливается и зависает на неопределенный срок. До вчерашнего дня у меня никогда не было причин запускать команду "top" на сервере, но при этом я понял, что Admin::Analytics#index заставляет mysqld вращаться при более чем 350+% мощности ЦП. четырехъядерный, производственный VPS.
Я загрузил свежие копии производственных данных и производственного журнала. Однако, когда я получаю доступ к Admin::Analytics#index локально на своем компьютере для разработки, используя рабочие данные, он загружается примерно через 10–12 секунд (и использует ~ 150+% моего двухъядерного процессора), что, к сожалению, нормально. . Я предполагаю, что могло быть несоответствие в настройках mysql, которое внезапно вступило в игру. Кроме того, mysqldump базы данных теперь составляет 531 МБ, тогда как 28 дней назад он составлял всего 336 МБ. В любом случае, у меня нет root-доступа к VPS, поэтому настройка производительности mysqld была бы обременительной, и мне бы очень хотелось добраться до точной причины этой проблемы. Однако производственные журналы не содержат информации. по запросам; они просто сообщают о продолжительности этих запросов, которая в среднем составляет несколько минут каждый (хотя они, похоже, заставляли mysqld останавливаться гораздо дольше, чем это, и побуждали меня запросить наш хост перезагрузить mysqld просто для того, чтобы наш сайт снова заработал). в одном экземпляре).
Я полагаю, что могу попытаться повысить уровень журнала в производстве, чтобы запросить информацию. на запросы к базе данных, выполняемые Admin::Analytics#index, но в то же время я боюсь воспроизвести это поведение в рабочей среде, потому что мне не хочется вызывать наш хост, чтобы снова перезапустить mysqld! Это действие содержит один запрос к базе данных в своем контроллере и пару десятков подготовленных операторов, встроенных в его представление!
Как бы вы приступили к тестированию/диагностике и оптимизации/исправлению этого действия?!
(Кроме того: очевидно, что я хотел бы полностью заменить эту функцию Google Analytics или аналогичным решением, но мне нужно решить эту проблему, прежде чем продолжить.)
