Издержки они и так сократили до такой степени, что люди работают на 15" мониторах, а если их это не устраивает, то идут в магазин и покупают подходящий за свои деньги, куда уж дальше? :-)
Сейчас всё, вроде бы, удалось решить, но говорить «много-мало» в данном случае как-то неправильно. Разве специфика отдельно взятых данных, структуры базы и запросов к ней ничего не решают? Разве можно сравнивать запросы одним только количеством :-)?
На хабре для каждого пользователя свои запросы и запросы довольно непростые, некоторые у меня не умещаются в экран. Чего стоит один только вывод постов и комментариев одной лентой? Лично я бы допускать этого в таком виде не стал, но здесь это есть. Как следствие - «using temporary; using filesort». Все эти количества комментариев, персонализированные ленты многого стоят. Для любого зарегистрированного пользователя кеширование практически сходит на нет.
С 6.2 на 6.2. MySQL 5. Разница версии в одну десятую.
Процессоры — с AMD 64 на новые четёрыхядерные ксеоны.
Там кроме прочего, были явные проблемы с таблицами, которые могли всплыть от dump-restore. Когда всё было в myisam то средствами repair/analyze/myisamchk ничего сделать не получалось, они просто висли. Приходилось пересоздавать проблемную таблицу.
Когда я работал в mail.ru то на моём проекте использовался nginx+apache+mod_perl. К моменту ухода рекорд был 1800000 хитов на один сервер web+база (news.mail.ru).
Проблемы были две:
* оптимизатор MySQL под нагрузкой начинал сходить с ума и брать неоптимальный индексы, приходилось долго и упорно расставлять их везде в виде use index, запросов было много, поэтому это был очень раздражительный и муторный процесс.
У нас там не было такого количества пямяти, поэтому скинуть всё на innodb не удавалось.
* mod_perl «тёк» (да, не высвобождал память, но в каких-то слишком значительных количествах), поэтому апачи должны были перезапускаться время от времени по maxrequests
The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size. However, do not set it too large because competition for physical memory might cause paging in the operating system.
Насколько моя память помнит, для myisam основные опции — параметры для буфера запросов и сортировки, помню, что когда я этим занимался, я не нашёл ничего такого, что позволилось бы ему с ногами залезть в память. Может быть, конечно, я просто что-то упустил.
До момента предоставления значительного количества памяти mysql потреблял 100-300% ЦПУ (в системе числится 8 процессоров от двух четырёхядерных ксеонов), как только таблицы были переведены в innodb. С двумя гигабайтами потребление снизилось до 1-15% в обычном решиме и 100% в пиковом.
Сейчас всё, вроде бы, удалось решить, но говорить «много-мало» в данном случае как-то неправильно. Разве специфика отдельно взятых данных, структуры базы и запросов к ней ничего не решают? Разве можно сравнивать запросы одним только количеством :-)?
На хабре для каждого пользователя свои запросы и запросы довольно непростые, некоторые у меня не умещаются в экран. Чего стоит один только вывод постов и комментариев одной лентой? Лично я бы допускать этого в таком виде не стал, но здесь это есть. Как следствие - «using temporary; using filesort». Все эти количества комментариев, персонализированные ленты многого стоят. Для любого зарегистрированного пользователя кеширование практически сходит на нет.
Процессоры — с AMD 64 на новые четёрыхядерные ксеоны.
Там кроме прочего, были явные проблемы с таблицами, которые могли всплыть от dump-restore. Когда всё было в myisam то средствами repair/analyze/myisamchk ничего сделать не получалось, они просто висли. Приходилось пересоздавать проблемную таблицу.
Когда я работал в mail.ru то на моём проекте использовался nginx+apache+mod_perl. К моменту ухода рекорд был 1800000 хитов на один сервер web+база (news.mail.ru).
Проблемы были две:
* оптимизатор MySQL под нагрузкой начинал сходить с ума и брать неоптимальный индексы, приходилось долго и упорно расставлять их везде в виде use index, запросов было много, поэтому это был очень раздражительный и муторный процесс.
У нас там не было такого количества пямяти, поэтому скинуть всё на innodb не удавалось.
* mod_perl «тёк» (да, не высвобождал память, но в каких-то слишком значительных количествах), поэтому апачи должны были перезапускаться время от времени по maxrequests
The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size. However, do not set it too large because competition for physical memory might cause paging in the operating system.
Насколько моя память помнит, для myisam основные опции — параметры для буфера запросов и сортировки, помню, что когда я этим занимался, я не нашёл ничего такого, что позволилось бы ему с ногами залезть в память. Может быть, конечно, я просто что-то упустил.
До момента предоставления значительного количества памяти mysql потреблял 100-300% ЦПУ (в системе числится 8 процессоров от двух четырёхядерных ксеонов), как только таблицы были переведены в innodb. С двумя гигабайтами потребление снизилось до 1-15% в обычном решиме и 100% в пиковом.