Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Всем привет.
У нас с коллегами почти холивар начался, мы как лебедь, рак и щука. Вопросы остаются по процессору и памяти, с дисками вроде как определились.
Сейчас ксеон Е5 с 4/4 ядрами/потоками и частотой 2.4ГГц обычно загружен на 30-70%, 32Гб памяти заняты на 80%, объём БД - 350Гб (данные + индексы), ссд диски не редко нагружены на полную.
1. При выборе процессора предпочтение отдавать ядрам или тактовой частоте?
2. Как определить подходящий объём памяти?
Железо должно увеличить производительность СУБД, бюджет конечно же ограничен Хочется взять железо с небольшим запасом, БД постепенно растёт. На сервере кроме СУБД ничего не будет, используем Percona XtraDB Cluster.
По процессору склоняюсь к Xeon Silver на 10 ядер, но кто-то говорит, что вместо ядер лучше частоту 3ГГц+. Памяти 128-256Гб, но опять же, кто-то говорит, что нет смысла ставить много памяти, если она меньше объёма БД.
Краткая статистика RW ноды, если это будет полезно:
Неактивен
Было бы круто иметь универсальный ответ, но, к сожалению, универсального ответа нету Дальше несколько моих мыслей разной степени разумности.
Проще всего про память — памяти нужно столько, чтобы помещался активный сет данных. Можно условно прикинуть его по правилу Парето (80% хитов обычно приходят в 20% данных), но, возможно, есть способ и лучше. Неплохой способ — смотреть в статистику попаданий/промахов по кэшам, но он, очевидно, работает тогда, когда вы уже купили память, и пытаетесь выяснить, сколько ее выделить под БД Часто у вас есть какое-то внешнее понимание (например, есть 10% активных пользователей, а остальные заходят редко, тогда вам нужно держать в памяти 10% данных для этих пользователей).
Про процессоры мысли еще менее разумные. Увеличение количества ядер увеличивает пропускную способность запросов (они работают в параллели), но не увеличивает скорость работы отдельных запросов. Увеличение частоты увеличивает скорость работы запросов, но количество параллельно обрабатываемых запросов остается на том же уровне. Лично я бы, наверное, отдавал предпочтение частоте отдельных ядер. Причины такие:
1. При загрузке 30% у вас нету процессорного голодания, часть ядер в какие-то моменты простаивают, и увеличение количества увеличит количество этих простаивающих ядер
2. Чем больше реально параллельных задач, тем больше они начинают драться за mutexы над данными (например, mutex перед buffer pool), тем больше накладные расходы.
Ну тогда и аргумент в пользу большего количества ядер Скорее всего, в моменты, когда процессоры простаивают, вам и так уже достаточно производительности. А критично, когда происходит всплеск нагрузки. Сложные процессорные операции над своими данными (например, сортировку своих данных в памяти) отдельные ядра в параллели сделают быстрее для потребителей (никто не будет ждать освобождения ядра).
Неактивен
Спасибо за объёмный ответ, хоть он и в сферическом вакууме
Неактивен
Страниц: 1