Outsourcenow

Рейтинг
26
Регистрация
13.08.2008
Интересы
Unix, web, highload.
netwind:

Memcached Cache (TCP/IP) - 12200
MySQL Query Cache (Unix Socket) - 13500

Прекрасный тест! :-)

netwind:
Outsourcenow, при этом предводитель "людей которые занимаются тюнингом" пишет статейки, как его использовать : http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/
Нестыковочка.

Дейстивтельно :-) Потому как именно Петя в 2008 году говорил строго обратное :-)

netwind:
Outsourcenow, ну вот. 90% апдейтов в вебе это нетипично. Специфика вашего проекта совсем не дает вам право утверждать, что у mysql хреновый query_cache.

Ну, я только за себя говорить могу - поэтому такой пример и привел. Но люди, которые всерьез нанимаются тюнингом высоконагруженного mysql настоятельно отговаривали от использования кэша :-)


А так, попробуйте уменьшать (как ни странно) размер кеша. Сделайте профилирование. Скорее всего, накладные расходы возникают не при поиске в кеше, а при удалении затронутых обновлением запросов из кеша. Это не значит, что бороться этим явлением невозможно.

Не, это мертвому припарки. Там программисты уже озадачены переписыванием всего этого на мемкэше с периодическим дампом в mysql.

netwind:
Outsourcenow, так вы не ответили почему он тормозит именно в вашем приложении. hitrate хотя бы какой у вас?

хитрейт - порядка 60%. Но на той железке - около 90% апдейтов. Копеечного размера таблицы, нормированые - но с часто обновляемыми данными.

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

Roxis:
Не кешерует оно запросы содержащие "now()" или многие другие функции.

Ну, в принципе, про now() мог и соврать :-)

netwind:
Outsourcenow, надо. у вас, видимо, приложение специфическое.

query_cache внутри - простой, как молоток. Фактически, это просто хэш в памяти, где ключем выступает строка запроса.

Поэтому реальный плюс от него - только в запросах вида "select * from table;". Более того, запрос "select id from table where name="asdf";" и "SELECT id from table where name="asdf";" - это разные запросы.

Что еще веселее - оно кэшиурет запросы "select ... where dtime = now();". Учитывая, что сам кэш - fifo - это офигительно сказывается на КПД :-)

Да, в проектах "домашняя страничка василия пупкина" это работает прекрасно. Если же у вас идеологически верная архитектура, и правильно спроектированная БД - то query_cache не поможет, а только навредит.

netwind:
Andreyka, ну мне что, опять написать программу, которая покажет вам 5K qps ? :)
факт на лице : в mysql есть query_cache и он работает, причем даже раньше парсинга sql.

Я вам страшное скажу.

query_cache работает хреново :-)

Если я на машине с 8k qps включаю query_cache - qps падает до 3-5k, вагон локов в базе, крах, крушение всех надежд ;-)

Выключаю - все опять хорошо.

Причины объяснять надо? :-)

Andreyka:
Хотя еще раз повторю - я против райзера, у меня был случай креша, с xfs все ок

Крашится все :-)

Только вот райзер застрял, и развиваться больше по-человечески не будет, Хансу еще сидеть и сидеть :-)

Outsourcenow добавил 11.02.2009 в 12:16

Dr. Botwing:
А мне вот в качестве серверной платформы больше BSD импонирует..

Thanks, Capt.! :-)

Andreyka:
Я использую gentoo на виртуалках под проекты с нестандартными требованиями

А, кстати, почему генту внутри? Почему не центос?

По мне - наклепать свой собственный репозиторий со сборками всякого хлама так, как надо - наиболее удобный вариант.

netwind:

Про то, что ffmpeg в убунтах есть готовый в ОСНОВНОМ репозитарии, включая все биндинги даже на php, надеюсь не надо напоминать?

Конечно не надо :-)

Прекрасно, что он там есть - но это не сглаживает впечатление от ублюдочного dpkg :)

Всего: 331