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