MySQL на HDD и SSD

[Fragster]

если памяти много — то можно тупо на tmpfs или ramdrive кинуть БД — и все будет летать… (по крайней мере с 1с такой подход прокатывает). только нужен УПС большой и свой демон синхронизации писать

[silentroach]

Если памяти много не нужно ничего никуда кидать, а просто отдать эту память под кеширование, которое и так в mysql есть.

[SovGVD]

под кеш mysql (по рекомендации скриптов оптимизации, которые кстаии говоря не ругаются уже на параметры) отдано 60% реальной памяти (включая ключи, временные таблицы и прочее) — ситуацию это коренным образом не поменяло

[silentroach]

Ну тут уже от тестов зависит. Возможно, ваш тест делает такие запросы, что кеш в них не поможет? Собственно, мой комментарий к статье не имеет отношения, я ответил чуваку, который базу в tmpfs кладет :)

[SovGVD]

имхо хранить базу в памяти — слишком рискованно =)

[nolled]

А на практике какова надежность такого решения?

[SovGVD]

я думаю как вариант — можно сделать репликацию на HDD, а то как то страшно в памяти хранить рабочую базу =)

[SovGVD]

если верить хостеру, то да

[SovGVD]

мне кажется задержка именно в связи SAN<->сервер
в момент тестирования сервер никем не нагружался

[SovGVD]

не знаю, вот ссылочка www.truevds.ru/about, но вообще в целом доволен ими

[SovGVD]

у меня сервачек just for fun в большей степени (несколько стартапов, наивно ожидающих наплыва посетителей) + эксперименты, вот и хотелось бы оттюнинговать mysql и прочие компоненты обычного lamp, так сказать на будущее
siege для теста подойдет? или всё таки не то?

[SovGVD]

а вдруг потом будет поздно?

[SovGVD]

в общем то SSD и брался в надежде на увеличения пропускной способности, так как ожидание ввода/вывода с HDD периодически было чудовищна (по 1-2 секунды без ответа при банальном чтении)

[SovGVD]

Чем бы потестить хорошенечко задержки — редко они бывают.
Я так понимаю что %iowait в iostat показывает время задержки чтения/записи? дык вот иногда эта циферка бывает 100% в течении 2-3 секунд

[Psih]

Хотите знать про SSD и MySQL? Вам сюда: MySQL Performance Blog от Percona Inc
А вот вам выдержка по тегу SSD. Приятного чтения!

[sply]

На этих VDS тест нормально не сделать:
1) в SAN большие дисковые буферы и здесь они влияют на результат тестирования больше, чем сами диски
2) MySQL использует собственные буферы в памяти
3) Последовательные или однопоточные операции на HDD и SSD будут примерно одинаковы. Заметная разница появляется только на random seeks — на многопоточных операциях.

[SovGVD]

короче говоря, лучше мне на этот SSD перенести кеш и часто запрашиваемые файлы?

[sply]

Сколько в сумме занимают кэш и эти файлы? Если до 100 Мб (<20..30% физической RAM), то их можно держать где угодно, все равно самое нужное осядет в оперативной памяти. А если под 500-1000 Мб и все дергаются часто, то да, ОЗУ для кэширования будет мало и SSD хорошо поможет.

Большие файлы (больше 1 Мб) на SSD держать не имеет смысла, они хорошо читаются большим куском с HDD. А идеальный случай для SSD — большой набор мелких юзерпиков и тумбнейлов.

[SovGVD]

кешки не более 500 кб на файл (смотря сколько юзер текста наваяет), картинки мелкие по 20-300 кб

[sply]

Кстати, мы когда готовили SSD к запуску, гоняли тесты системы с отключенными кэшами, чтобы видеть реальный результат. Начиная с 4 параллельных потоков производительность на SSD превышала производительность на HDD в 20 раз и где-то на 10-15 потоках поднималась до 40.

Я даже статью для Хабра по результатам набросал, но не было времени нормально причесать и закончить, так где-то в черновиках пылится.

[SovGVD]

на SSD было всё? или только данные?
ну и хотелось бы почитать статейку =)

[sply]

Только данные
Вот летом станет забот поменьше, опубликую обязательно :)

[Lebnik]

где же статейка? лето ведь уже давно прошло… очень ждемс

[delfi]

да, было бы неплохо, 10 лет как ждем

[xiWera]

большинство современных SSD проигрывают HDD по IOPS на случайную запись маленькими блоками