Некоторое последнее время пришлось плотно заниматься нагрузочным тестированием одного из проектов. Там у нас используется Liferay 6.1.0 CE и база данных MySQL 5.5
Так вот - в ходе тестирования под нагрузкой обратили внимание - что в какой-то момент времени распределение процессорного времени начинается не в пользу Liferay: мускул начинает отъедать 300% - оставляя Liferay только 100%.
Это показалось странным, так как обычно картина обратная - Liferay (вернее скорость процессора под него) является бутылочным горлышком - и именно Liferay в основном грузит систему - влияние базы минимально.
Более детальный разбор полетов позволил выяснить - что виноват во всем Asset Publisher (Публиктор по русски) - а вернее те запросы к таблице AssetEntry & co которые он генерит. Иногда запрос "вставал" на 15 секунд(!!!) - при том что записей у нас там примерно 25k
Профайлинг запроса ничего не дал - все индексы какие можно используются, все вроде как надо - просто - запрос хитрый и в результате его выполнения идет выборка большого кол-ва данных.
Честно пробовали тюнить mySQL - конфигурировать кеши, буфера и пр. Не помогло. Ну и , я конечно понимаю тюнинг базы данных когда счет кол-ва записей идет на миллионы, но не десятках тысяч же!
В итоге проблема решилась тем, что мы научились кешировать вывод любого портлета - нам этого хватило. Ну и все-равно - проблемы с производительностью начинались у сайта при нагрузке на порядок выше текущей - запас есть. Но неприятный осадок остался.
В ходе тестирования было высказано экспертное мнение, что PostgreSQL должен вести себя на таких запросах лучше.
Итак, в какой-то момент мы все-таки нашли время и провели эксперимент: запустили две одинаковые машинки на амазоне, поставили там один и тот же Liferay (со всеми портлетами и данными), на одном копию базы на MySQL, на другом сделали миграцию данных на PostgreSQL ( кстати, миграция данных средствами Liferay прошла на ура)
И стали смотреть. MySQL работал как и ожидалось, а вот PostgreSQL удивил.... дикими тормозами. То есть - главная страница могла открываться минуту!
Долго смотрели, пытались тюнить, конфигурировать - слабо помогало. В принципе выяснилось что проблема та же - большое количество запросов при отрисовке страницы, и большая выборка данных. Просто если MySQL на этом еще пролетал как-то - то PostgreSQL вставал колом.
К тому же скорей всего сказалось то, что PostgreSQL более критичен к скорости дисковых операций - а у нас EC2 были подняты на "медленном" EBS - видимо это тоже внесло свою лепту.
Что делать?
После некоторых изысканий была найдена следующая бага: http://issues.liferay.com/browse/LPS-28364 - как раз про наш случай - Asset Publisher на Liferay 6.1.0
После бекпорта фикса с 6.1.1 на 6.1.0, и исправления баги http://issues.liferay.com/browse/LPS-31539 (она же Asset Publisher can't handle the multilevel categories - кто использует 6.1.1 - обратите внимание - она там по прежнему есть) PostgreSQL полегчало несколько - страница стала открываться быстрее (заметно) - но общая скорость работы все равно далека от MySQL
И какие из этого следуют выводы?
По большому счету никаких. Нельзя сказать что MySQL быстрее чем PostgreSQL только на данном специфическом примере. И нельзя сказать что Liferay быстрее на MySQL чем на PostgreSQL.
И понятно что любую базу можно оттюнить так - что она начнет работать значительно быстрее (хотя опять-таки, 25k записей - не та база которую надо тюнить)
И в вашем случае вполне возможно Asset Publsiher-ы вообще не используются, и вам проблема с их производительностью неважна. Или у вас такое железо, на котором PostgreSQL просто летает.
Но для себя мы выводы сделали - менять основную базу, которую мы используем по умолчанию, с MySQL на PostgreSQL смысла нет. По крайней мере используя с настройками по умолчанию мы ничего не выиграем - а глядишь и проиграем.
3 комментария:
Очень удивлен. Никак не ожидал такого результата от Postgres. Мы в основном только на Postgres и работаем, но с такого рода проблемами не сталкивались ни разу.
Не забудь еще, что оптимизатор стремился использовать seq scan, после его отключения в конфиге заметно полегчало. Кроме того, были моменты, когда java жрала процессор, а постгрес стоял. Страницы в этот момент не отрисовывались. Есть предположение, что шла активная сборка мусора, но это не проверялось. Вообще, ужас, конечно.
Слава - тем не менее - после всех оптимизаций psql система на mySQL (с настройками мускула по умолчанию) оказалась в два раза быстрее допиленной (как минимум на уровне настроек) PostgreSQL. Настройки Java в обоих случаях одинаковые. Вывод пока прежний - у нас был резон перехода на psql как раз с ожиданиями что запросы к ассетам будут работать лучше. Это не так. Учитывая что psql требует еще и серьезного допила что бы он начал адекватно работать - на что у нас нет ресурсов - пока остаемся на mysql в качестве основной базы.
На самом деле хочется еще попробовать с ораклом и MSSQL - благо и тот и другой есть в виде RDS на Амазоне
Отправить комментарий