Как стать автором
Обновить

Комментарии 34

НЛО прилетело и опубликовало эту надпись здесь
если памяти много — то можно тупо на tmpfs или ramdrive кинуть БД — и все будет летать… (по крайней мере с 1с такой подход прокатывает). только нужен УПС большой и свой демон синхронизации писать
Если памяти много не нужно ничего никуда кидать, а просто отдать эту память под кеширование, которое и так в mysql есть.
под кеш mysql (по рекомендации скриптов оптимизации, которые кстаии говоря не ругаются уже на параметры) отдано 60% реальной памяти (включая ключи, временные таблицы и прочее) — ситуацию это коренным образом не поменяло
Ну тут уже от тестов зависит. Возможно, ваш тест делает такие запросы, что кеш в них не поможет? Собственно, мой комментарий к статье не имеет отношения, я ответил чуваку, который базу в tmpfs кладет :)
имхо хранить базу в памяти — слишком рискованно =)
А на практике какова надежность такого решения?
я думаю как вариант — можно сделать репликацию на HDD, а то как то страшно в памяти хранить рабочую базу =)
НЛО прилетело и опубликовало эту надпись здесь
если верить хостеру, то да
НЛО прилетело и опубликовало эту надпись здесь
мне кажется задержка именно в связи SAN<->сервер
в момент тестирования сервер никем не нагружался
НЛО прилетело и опубликовало эту надпись здесь
не знаю, вот ссылочка www.truevds.ru/about, но вообще в целом доволен ими
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
у меня сервачек just for fun в большей степени (несколько стартапов, наивно ожидающих наплыва посетителей) + эксперименты, вот и хотелось бы оттюнинговать mysql и прочие компоненты обычного lamp, так сказать на будущее
siege для теста подойдет? или всё таки не то?
НЛО прилетело и опубликовало эту надпись здесь
а вдруг потом будет поздно?
НЛО прилетело и опубликовало эту надпись здесь
в общем то SSD и брался в надежде на увеличения пропускной способности, так как ожидание ввода/вывода с HDD периодически было чудовищна (по 1-2 секунды без ответа при банальном чтении)
НЛО прилетело и опубликовало эту надпись здесь
Чем бы потестить хорошенечко задержки — редко они бывают.
Я так понимаю что %iowait в iostat показывает время задержки чтения/записи? дык вот иногда эта циферка бывает 100% в течении 2-3 секунд
На этих VDS тест нормально не сделать:
1) в SAN большие дисковые буферы и здесь они влияют на результат тестирования больше, чем сами диски
2) MySQL использует собственные буферы в памяти
3) Последовательные или однопоточные операции на HDD и SSD будут примерно одинаковы. Заметная разница появляется только на random seeks — на многопоточных операциях.
короче говоря, лучше мне на этот SSD перенести кеш и часто запрашиваемые файлы?
Сколько в сумме занимают кэш и эти файлы? Если до 100 Мб (<20..30% физической RAM), то их можно держать где угодно, все равно самое нужное осядет в оперативной памяти. А если под 500-1000 Мб и все дергаются часто, то да, ОЗУ для кэширования будет мало и SSD хорошо поможет.

Большие файлы (больше 1 Мб) на SSD держать не имеет смысла, они хорошо читаются большим куском с HDD. А идеальный случай для SSD — большой набор мелких юзерпиков и тумбнейлов.
кешки не более 500 кб на файл (смотря сколько юзер текста наваяет), картинки мелкие по 20-300 кб
Кстати, мы когда готовили SSD к запуску, гоняли тесты системы с отключенными кэшами, чтобы видеть реальный результат. Начиная с 4 параллельных потоков производительность на SSD превышала производительность на HDD в 20 раз и где-то на 10-15 потоках поднималась до 40.

Я даже статью для Хабра по результатам набросал, но не было времени нормально причесать и закончить, так где-то в черновиках пылится.
на SSD было всё? или только данные?
ну и хотелось бы почитать статейку =)
Только данные
Вот летом станет забот поменьше, опубликую обязательно :)
где же статейка? лето ведь уже давно прошло… очень ждемс
да, было бы неплохо, 10 лет как ждем
большинство современных SSD проигрывают HDD по IOPS на случайную запись маленькими блоками
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории