Re: Как тюнить дисковую систему?
- From
- Andrey N. Oktyabrski (2:5020/400)
- To
- Dmitry Miloserdov
- Date
- 2006-04-13T09:59:24Z
- Area
- RU.UNIX.SOLARIS
From: "Andrey N. Oktyabrski" <ano@bestmx.ru>
Dmitry Miloserdov wrote:
> Hello, Andrey!
> You wrote to me on Tue, 11 Apr 2006 14:01:20 +0000 (UTC):
> ??>> 1. прежде чем увеличить производительность чтения может стоит подумать
> ??>> почему у тебя 30-50% записи.
> ANO> Так затык-то не в записи. Даже когда записи 5-10%, всё равно упирается
> ANO> в чтение.
> ??>> 2. Если у тебя не innodb то forcedirectio только мешает.
> ANO> Да это я пробовал его включить, с ним оказалось хуже, но не фатально
> ANO> хуже. Выключил - стало чуть лучше, но ненамного.
> Ну если ты хотел чуда то его не будет. Если базе действительно нужно
> считать/записать больше чем железка может то тут врядли что поделаешь.
Чуда не хотел, чудес и так больше чем хотелось бы :-) Нашли вот вчера
подозрительный моментик:
Another problem is that the optimization is lost when you have an OR on
a prefix of the index:
SELECT * FROM t1 FORCE INDEX (key1_key2_key3)
WHERE key1=1 OR key1=2 ORDER BY key2,key3 LIMIT 5, 5;
То есть field1 in (...) не даёт оптимизировать сортировку с
использованием индексов. Пробуем ликвидировать подобные запросы,
посмотрим что получится...
> Но есть два момента:
> 1. почему у тебя затык происходит на 6M/s Если диски не в антикварном
> магазине куплены то как минимум раза в 3-4 быстрее должны быть.
> на последовательных чтении/записи тоже скорость выше не поднимается?
> кстати драйвер у тебя lsimega или еще amr
lsimega, про amr я прочитал перед тем как систему ставить не самые
лестные отзывы. Диски хорошие, только на них может быть включён кэш
записи - единственный подозрительный момент, и проверить не могу
(машинка в Москве, я в Краснодаре). Но мысль понятна - посмотреть на диски.
> 2. действительно ли все запросы столь хаотичны - 4G это все-таки не мало
> для mysql. В /db кроме собственно баз ничего нет? какой-нибудь query-log
> случайно туда не пишется? или там tmp-dir не туда смотрит?
> Вобщем дождаться проблемного момента и посмотреть не только на iostat
> но также на vmstat и vmstat -p.
Ничего кроме мускула там нет. tmp-dir смотрит на /var/tmp - на другом
разделе. query-log выключен вообще. Проблемный момент сейчас уже только
создавать, дождаться не получится, потому что одну из баз перекинул на
другую машинку, нагрузка упала. Но вернуть её когда-то надо будет,
желательно после того как найду причину тормозов :-)
> ANO> Кстати, про innodb - стОит пробовать, или не будет быстрее чем
> ANO> myisam?
> А вот тут не скажу наверняка, но innodb не позиционировался как "скоростное"
> решение так что врядли будет лучше.
Я про него слышал разные мнения, видимо придётся всё-таки пробовать на
конкретном железе/системе/софте...
И всё-таки о контроллере - 320-2Х скорости не добавит? Или он только на
пятом рейде даст большое преимущество благодяря более быстрому
процессору, а на десятом по барабану?
--- ifmail v.2.15dev5.3
* Origin: MTU-Intel ISP (2:5020/400)
SEEN-BY: 46/50 50/203 450/159 186 1024 451/30 461/640 469/999 4625/8 4627/10
SEEN-BY: 5000/76 5000 5001/5001 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28
SEEN-BY: 5020/175 194 400 545 715 758 830 902 937 1042 1169 1523 1604 1922
SEEN-BY: 5020/2020 2238 4441 5021/29 5022/128 5025/3 750 5026/45 5030/49 115
SEEN-BY: 5030/436 556 966 1900 1957 5031/47 5035/3 38 5036/1 5040/47 5045/7
SEEN-BY: 5051/15 5053/16 5054/1 4 8 9 28 35 37 5057/1 5060/88 5061/15 120
SEEN-BY: 5062/1 10 5064/7 5066/18 5067/2 5070/1222 5074/9 5075/5 5080/80 1003
SEEN-BY: 5082/6 5083/21 5085/13 5090/113 5093/57 5095/20 5096/18 6000/0 1
SEEN-BY: 6001/3
PATH: 5020/400 4441 545 5054/1 37