md0 : active raid1 sda1[0] sdc1[1] 505920 blocks [2/2] [UU]
lnmonq14aqqqqqqqqqqqqqqqqqqqqqHostname=d3qqqqqqqqqqqRefresh= 2secs qqq14:52.40qqqqqqqqqqqqqqqqqk x Disk I/O qq/proc/diskstatsqqqqmostly in KB/sqqqqqWarning:contains duplicatesqqqqqqqqqqqqqqqqqx xDiskName Busy Read WriteKB|0 |25 |50 |75 100| x xsda 26% 373.6 1118.9|RRRRWWWWWWWW> | x xsda1 0% 0.0 0.0|> | x xsda2 26% 373.6 1118.9|RRRRWWWWWWWWW> | x xsdb 0% 0.0 0.0|> | x xsdb1 0% 0.0 0.0|> | x xsdc 36% 323.7 1118.9|RRRRRWWWWWWWWWWWWW> | x xsdc1 0% 0.0 0.0|> | x xsdc2 37% 323.7 1118.9|RRRRRWWWWWWWWWWWWW> | x xmd0 0% 0.0 0.0|>disk busy not available | x xmd1 0% 697.3 1110.9|>disk busy not available | x xdm-0 0% 0.0 0.0|> | x xdm-1 0% 0.0 0.0|> | x xdm-2 35% 697.3 1110.9|RRRRRRRWWWWWWWWWWW> | x xTotals Read-MB/s=2.7 Writes-MB/s=6.5 Transfers/sec=858.1 x xqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqx
Второй вопрос (про сата диски): случайно не подскажете какой интерфейс у WD-шных велоцерапторов? ;)
Пропускная способность интерфейса SATA2 - 3 Гбит/с, SATA3 - 6 Гбит/с. Этого более чем достаточно, чтобы разместить и 20 и 200 впсок. Другое дело, что узкое место - рандомный доступ и тут скорость оборотов рулит.
Вот хорошая иллюстрация про рандомный доступ:
WD'шные рапторы имеют скорость вращения 10к и интерфейс, сюрприз, SATA.
Как видно из графика 10к имеет преимущество в 2 раза по сравнению с 7.2к
15к - всего лишь в полтора раза по сравнению с 10к. Ну и конечно же совершенно пофиг какой это интерфейс обмена данными :)
Так что сказки про плохие рейды и сата диски рассказывайте кому-то другому :)
Если руки из одного места - не помогут ни SAS'ы, ни SSD :)
Надо просто правильно железо подбирать :)
P.S. В более презентабельном варианте 20 ВПСок на сата дисках выглядят так (во время ночного бекапа видно какой запас по IO есть):
alukart: mysql> show processlist;
+-------+---------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+---------+-----------+------+---------+------+-------+------------------+
| 17001 | alukart | localhost | NULL | Query | 0 | NULL | show processlist |
+-------+---------+-----------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)
Ну так MySQL ничего и не делает. Курит себе, отдыхает. Очевидно, проблема не в нем.
В консоли mysql посмотрите "show processlist;", чтобы иметь представляет о том, чем занят мускл. И выкладывайте результат сюда. Дальше будем обсуждать.
А VDS часом не FreeBSD 8.х 64 битная?
Тут недавно на 64 битной восьмерке глюк поймали: один и тот же запрос несколько сотен раз выполняется нормально, а во время очередного стопиццотого запроса рвется коннект и MySQL server has gone. На всех версиях MySQL: 4.1, 5.0, 5.1. После общения с ребятами из перконы проблема решилась апом mysql до девелопмент ветки 5.5.
Та да, расскажите. Попробуйте поднять ноду с 20 впсками на фотором райд 1 из сата дисков...
Первый вопрос: и в чем проблема?
Второй вопрос (про сата диски): случайно не подскажете какой интерфейс у WD-шных велоцерапторов? ;)
Пропускная способность интерфейса SATA2 - 3 Гбит/с, SATA3 - 6 Гбит/с. Этого более чем достаточно, чтобы разместить и 20 и 200 впсок. Другое дело, что узкое место - рандомный доступ и тут скорость оборотов рулит.
Вот хорошая иллюстрация про рандомный доступ:
WD'шные рапторы имеют скорость вращения 10к и интерфейс, сюрприз, SATA.
Как видно из графика 10к имеет преимущество в 2 раза по сравнению с 7.2к
15к - всего лишь в полтора раза по сравнению с 10к. Ну и конечно же совершенно пофиг какой это интерфейс обмена данными :)
Так что сказки про плохие рейды и сата диски рассказывайте кому-то другому :)
Если руки из одного места - не помогут ни SAS'ы, ни SSD :)
Надо просто правильно железо подбирать :)
P.S. В более презентабельном варианте 20 ВПСок на сата дисках выглядят так (во время ночного бекапа видно какой запас по IO есть):
ну тогда см. личку
вот собственно сайт bookivedi. ru - путешевствуя по разделам - довольно медленно открываются страницы - точнее генерируются
вот собственно что когда открывается сайт
Могу еще предложить MySQL query cache попробовать
в my.cnf в секцию mysqld добавить:
query_cache_type = 1
query_cache_size = 32M
Но что-то мне подсказывает, что толку много не будет.
mysql> show processlist;
+-------+---------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+---------+-----------+------+---------+------+-------+------------------+
| 17001 | alukart | localhost | NULL | Query | 0 | NULL | show processlist |
+-------+---------+-----------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)
Ну так MySQL ничего и не делает. Курит себе, отдыхает. Очевидно, проблема не в нем.
deltahost.com.ua добавил 31.12.2010 в 14:16
уже все кеширование максимально включено
Чудес не бывает. Тогда меняйте хостера.
Узнайте ухостера тип дискового массива - возможно в этом проблема.
Тип дискового массива не может быть проблемой. Ни один тип массивов сам по себе не может быть проблемой.
В консоли mysql посмотрите "show processlist;", чтобы иметь представляет о том, чем занят мускл. И выкладывайте результат сюда. Дальше будем обсуждать.
А VDS часом не FreeBSD 8.х 64 битная?
Тут недавно на 64 битной восьмерке глюк поймали: один и тот же запрос несколько сотен раз выполняется нормально, а во время очередного стопиццотого запроса рвется коннект и MySQL server has gone. На всех версиях MySQL: 4.1, 5.0, 5.1. После общения с ребятами из перконы проблема решилась апом mysql до девелопмент ветки 5.5.
так не бывает :)
см. подпись
Windows VDS:
http://deltahost.com.ua/vds.html
Форексеры брали, пользуются, довольны.
Сейчас взяли VDS 1000 Mhz, 512 Mb, 20$ в месяц, но я только перекинул 10 сайтов, как начались проблемы.
Очень странно. Похоже, что у вас там голый апач без nginx.