Мы пытаемся оптимизировать производительность hazelcast, и мы запускаем кластер из 16 узлов (8 ядер виртуальных машин), так что у нас всего 4001 раздел в кластере, и мы настроили 50 рабочих потоков на узел. Нам нужно повышение производительности, т.е. более высокая пропускная способность и меньшее время отклика, поэтому мы также думаем о настройке hazelcast.operation.generic.thread.count.
1) В чем разница между hazelcast.operation.generic.thread.count и hazelcast.operation.thread.count? Какие операции выполняет hazelcast.operation.generic.thread?
2) Соотношение между количеством разделов и потоков операций составляет примерно 5: 1, мы намерены уменьшить это соотношение, так как предполагаем, что это улучшит производительность. Что рекомендуется: увеличивать количество узлов или не использовать количество рабочих потоков в одном и том же количестве узлов?
3) Целесообразно ли линейное масштабирование узлов hazelcast с сохранением количества ядер и памяти в нашей ситуации?
Как описано здесь, http://docs.hazelcast.org/docs/3.10.4/manual/html-single/index.html#partition-aware-operations, hazelcast.operation.thread.count
управляют размером пула потоков для операций с учетом разделов, таких как imap.get/put/delete
и т. д. Если вы хотите улучшить производительность этих операций, вы можете изменить это свойство. Значение этого свойства по умолчанию - количество ядер ЦП, в вашем случае 8.
hazelcast.operation.generic.thread.count
управляет размером пула потоков для общих операций. например, iexecutor.execute
и т. д. Я считаю, что вам неинтересно повышать производительность для таких операций.
Один важный момент: если у вас 4001 раздел, каков размер ваших данных? Hazelcast предполагает, что раздел должен составлять от 50 до 100 МБ. (Пожалуйста, проверьте https://hazelcast.com/resources/hazelcast-deployment-operations-guide/) Итак, в вашем случае я ожидаю, что вы предоставили данные 200-400 ГБ. В противном случае это означает, что у вас слишком много маленьких разделов. Это тоже влияет на производительность.
Поскольку у вас 8 ядер на каждой виртуальной машине. установка количества потоков операций на 50 не слишком увеличивает производительность, потому что у вас 16 * 8 = 124 ядра ЦП в кластере. Если вы не добавите больше ЦП, простое увеличение количества потоков не приведет к увеличению производительности, по крайней мере, через некоторое время. Поэтому вам следует добавить больше узлов в кластер или увеличить количество ЦП для каждой виртуальной машины. Это сильно повлияет на производительность.
Если у вас уже есть лицензия Enterprise для хранения данных вне кучи, я предлагаю вам обратиться в службу поддержки Hazelcast.
Мы планируем хранить около 600 ГБ данных в собственной памяти hazelcast с дополнительными 150 ГБ для native.meta.memory. Теперь вернемся к количеству ядер, пока что, даже когда мы добавляем в систему большие, то есть 12 Кбайт записи в секунду и 60 Кбайт чтения в секунду, загрузка ЦП не превышает 30%. Мы не можем вернуться к нашей инфракрасной команде без объяснения причин, по которым нам нужно больше процессоров, когда мы не полностью используем то, что у нас есть.