Судя по тому, что ты пишешь с теорией у тебя так же плохо как и с практикой. Расскажи уже нам, что ты хочешь получить в результате своего тюненга? Если ты не можешь внятно ответить на этот вопрос, значит тебе пока ничего нельзя трогать.
>Расскажи уже нам, что ты хочешь получить в результате своего тюненга? Если ты не можешь внятно ответить на этот вопрос, значит тебе пока ничего нельзя трогать.
максимально эффективное использование памяти.. интересует именно тюнингование кэшей. все на myisam, запросы ниразу не оптимизированы. очень много
некоторые показатели:
uptime: 11 дней, 22 часов, 2 минут и 16 секунд
Статистика запросов: со времени запуска, на сервер было отослано запросов - 252,340,584.
Всего ø в час ø в минуту ø в секунду
252 M 882.19 k 14.70 k 245.05
Handler_read_rnd 86 M
Handler_read_rnd_next 10 M
Qcache_lowmem_prunes 210 k
Created_tmp_disk_tables 466 k
Key_reads 307 k
Select_full_join 598
Opened_tables 111 k
смотришь запросы EXPLAIN'ом ... если индексы не используются, вставляешь принудительно их использование USE INDEX, потом берешь memcached и вставляешь в код, где идет обращение к СУБД ... тем самым то понизишь нагрузку на sql сервер в разы ... учитывая, что юзаешь пхп, то с этим проблем не будет ...
вообще смотри запросы, они не должны превышать 1 секунды )) у меня были запросы по 12 секунды ...
> запросы однотипные (сайты на битриксе и на самописной cms)
Не в этом дело. Это преимущественно select? Дело в том, что при обновлении или изменении какого либо поля, либо зависимого поля из закешированного запроса приведёт к его сбросу и новой выборке => эффективность 0.
>смотришь запросы EXPLAIN'ом ... если индексы не используются, вставляешь принудительно их использование USE INDEX, потом берешь memcached и вставляешь в код, где идет обращение к СУБД
код - совсем не моя SOA
>тем самым то понизишь нагрузку на sql сервер в разы
а вообще кэшируй готовые страницы и складывай куда-нить, потом по md5 хэшу урла отдавай их ... и sql не нужен особо, запустишь скрипт для обновления страниц раз в 20 минут и все нормально будет )))
>Но это всё имеет смысл когда отношение READ к WRITE хотя бы 20 к 1.
insert 161 k 560.29 0.06%
insert select 12 k 41.05 0.00%
select 3,135 k 10.94 k 1.24%
update 499 k 1,740.07 0.20%
на данный момент:
query cache min res unit 4,096
query cache size 134,217,728
query cache type ON
P.S. битрикс та еще гадость...
> ради интереса естественно.. попытка разобраться с вопросом пока есть возможность - мощная не загруженная машина + куча реальных БД
Тюнинг - это решение некоей проблемы производительности. "Тюнить" нормально работающую систему, к тому же не обременную никакой нагрузкою - удел недалёких.
>Тюнинг - это решение некоей проблемы производительности. "Тюнить" нормально работающую систему, к тому же не обременную никакой нагрузкою - удел недалёких.
песец логика.. пока грям не грянет - не перекрестимся?
>тогда стоит отказаться от битрикса в пользу Ц иль че-нить вроде Раби/Питона ... поставить фронтэнд какой-нить вроде лайти иль нгинкс ... итд.
ога, а еще сменить технологию производства оперативы (использовать генно-модифицированный разумный мох из окресностей альфа-центавры), отрастить пару лушних щупалец и наконец сходить постричься..
p.s. nginx естественно юзается, но на серверах с апачем а не с mysql :)