|
MySQL.RU - Webboard
 Вернуться
 Оптимизация для медленного диска (Dst) 17/12/2011 - 02:24:09
 Re: Оптимизация для медленного диска (Akina) 17/12/2011 - 23:09:26
> Original message text:
> From: Dst - 17/12/2011 - 02:24:09
> Subject:Оптимизация для медленного диска
> -----------------
> Здравствуйте. Есть малобюджетный сервер, на котором стоит "зеленый" (следовательно, небыстрый) жесткий диск. В БД хранятся следующие данные данные:
> * 3 больших таблицы InnoDB с сотнями миллионов записей, индекс только по id. Каждая таблица - в отдельном файле. В секунду осуществляются десятки-сотни чтений и записей к каждой.
> * Несколько небольших таблиц MyISAM. С ними проблем нет.
> Проблема состоит в том, что производительность ограничена записью в БД, т.е. уже при 150-200 запросах в секунду диск перестает справляться с нагрузкой. Другая проблема в том, что дисковую систему проапгрейдить затруднительно.
>
> Переменные примерно такие:
> skip-external-locking
> key_buffer_size = 256M
> max_allowed_packet = 1M
> table_open_cache = 10
> sort_buffer_size = 2M
> read_buffer_size = 32M
> read_rnd_buffer_size = 16M
> myisam_sort_buffer_size = 64M
> thread_cache_size = 16
> query_cache_size = 16M
> thread_concurrency = 8
> max_delayed_threads=4
> tmp_table_size = 64M
> max_heap_table_size=64M
> myisam_recover
> net_read_timeout=300
> net_write_timeout=600
> innodb_additional_mem_pool_size = 16M
> innodb_buffer_pool_size = 1G
> innodb_data_file_path = ibdata1:10M:autoextend
> innodb_write_io_threads = 2
> innodb_read_io_threads = 2
> innodb_thread_concurrency = 9
> innodb_flush_log_at_trx_commit = 1
> innodb_log_buffer_size = 8M
> innodb_log_file_size = 128M
> innodb_max_dirty_pages_pct = 90
> innodb_lock_wait_timeout = 120
> innodb_file_per_table
> skip-federated
>
> Подскажите, можно ли добиться увеличения производительности без апгрейда железа?
>
From: Akina - 17/12/2011 - 23:09:26
Subject:Оптимизация для медленного диска
-----------------
Давай включим соображалку.
Прошла секунда, поступило 200 запросов на запись.Допустим, каждый из 200 запросов инициирует запись всего одного сектора на жёстком диске. Допустим, что у тебя продвинутая подсистема работы с накопителями типа NSS, т.е. все запросы обрабатываются лифтом за один проход. И нам так повезло, что все секторы располагаются на соседних треках. У нас охренительно быстрый винт с track-to-track seek 2 мс. Сколько времени уйдёт... нет, не на запись, а только на поиск траков и позиционирование головок? 400 миллисекунд из имеющейся секунды...
А теперь представь, что записывать надо куда как больше, дисковая - дерьмо, винт - тормоз... можно ли обойтись без апгрейда, а? сам-то как думаешь...
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
40832
|
|
