Upgrade сервера. А что именно "качать"?

Объемные группировки обычно переделывают на субаггрегатные таблицы по старым данным + union новых горячих данных.

От сортировок текстов избавляются внутренним подзапросом c сортировкой без текстов и внешним запросом на выборку текстов. Можно еще tmpdir пересадить в tmpfs ( в freebsd 7.0 ), если действительно создаются файлы.

SATAII - это не показатель скорости винта для СУБД. Показатель - это число оборотов в минуту.

Да и переходите на линукс уже. Cпециальные сборки mysql - percona и outdelta выпускают только для linux. Оно вам надо патчить вручную?

а какая загрузка у вас дисковой подсистемы? нагрузку можно увидеть по iostat -x -c 5

да я понимаю, что можно так со структурой извращаться, что будет всё летать. Но учитывая постоянную переделку и кучу костылей такой метод - это нечто нереальное.

Винты стоят самые обычные десктопные. 250гиг/7200об.мин.

Поэтому и ищу метод решения без кардинальной переделки базы. Самое узкое место - работа с временными таблицами. Их надо либо както писать в панять или увеличивать работу дисков.

Про tmpfs оссень интересна. Кто нибудь пробовал такое? Есть производительность?

$ iostat -x -c 5

                        extended device statistics

device     r/s   w/s    kr/s    kw/s wait svc_t  b

ad1        1.7  26.3    31.4   593.1    0 139.7   5

ad3        0.0   0.0     0.2     0.0    0   1.4   0

                        extended device statistics

device     r/s   w/s    kr/s    kw/s wait svc_t  b

ad1        4.0  44.9    35.0   719.1    0   3.5   2

ad3        0.0   0.0     0.0     0.0    0   0.0   0

                        extended device statistics

device     r/s   w/s    kr/s    kw/s wait svc_t  b

ad1        0.0   0.0     0.0     0.0    0   0.0   0

ad3        0.0   0.0     0.0     0.0    0   0.0   0

                        extended device statistics

device     r/s   w/s    kr/s    kw/s wait svc_t  b

ad1        4.0  20.0    16.5   301.5    0   3.4   7

ad3        0.0   0.0     0.0     0.0    0   0.0   0

                        extended device statistics

device     r/s   w/s    kr/s    kw/s wait svc_t  b

ad1        1.0   1.0    16.0   127.8    0   5.1   1

ad3        0.0   0.0     0.0     0.0    0   0.0   0

вот както так.

запостите настройки mysql show global variables, вывод mysqlreport ( он красивее чистых счетчиков). счетчики show global status тоже запостите.

если используется innodb постите и show engine innodb status.

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

Можем помочь в данной проблеме, там не нужна кардинальная переделака базы, но запросы надо будет править. А так же оптимизировать настройки mysql и системы. Надо смотреть и детально обсуждать.

ээх. ну даже теоретически нельза оптимизировать запрос имеющий LIKE '%search%' по паре полей и в этом же запросе куча JOIN с парой связок "многое ко многим", полнотектовый доп. поиск и групировка с сортировкой по разным полям. И всё это ворочается в базе на несколько гигов общим объёмом и посещаеостью под 50к в сутки.

Уже наигрался с эксплэйном до тошноты Дальше некуда. Все индексы в памяти, всё, что можно кэшируется, сложные запросы обрабатываюся через очередь запросов с мониторингом общей нагрузки системы и т.д. Но несколько раз в день в пике всё-равно сервер "укапывается". Селяви.

Теперь, похоже, осталось только вываливание в память временных таблиц. Просто не ясно, а поможет ли?

NetBot, почему же. вместо like подключают полнотекстовой поиск

Upgrade way: Linux --> More RAM --> RAID

1) Под временные таблицы - tmpfs

2) memlock