как распределяются сеансы кассандры

Question

Я вижу процесс java cassandra на моем экземпляре linux, он использует ~ 38 ГБ памяти и показывает под ним ~ 700 потоков.

1. Когда какие-либо подключения к базе данных выполняются через python или java?Они становятся потоком под основным процессом Java или отдельным процессом ОС?
2. Что происходит, когда соединение кластера порождает несколько потоков, они также станут потоками в основном процессе?Если да, то как различить потоки соединения и потоки порождения соединения?
3. Память, выделенная для потоков сеанса, выделяется ли она под не-кучей памяти?

Обновление - @chris- здесь вывод команды tpstats

[username@hostname ~]$ nodetool tpstats
Pool Name                         Active   Pending      Completed   Blocked  All time blocked
ReadStage                              0         0      110336013         0                 0
ContinuousPagingStage                  0         0             31         0                 0
MiscStage                              0         0              0         0                 0
CompactionExecutor                     0         0        4244757         0                 0
MutationStage                          0         0       25309020         0                 0
GossipStage                            0         0        2484700         0                 0
RequestResponseStage                   0         0       46705216         0                 0
ReadRepairStage                        0         0        2193356         0                 0
CounterMutationStage                   0         0        3563130         0                 0
MemtablePostFlush                      0         0         117717         0                 0
ValidationExecutor                     1         1         111176         0                 0
MemtableFlushWriter                    0         0          23843         0                 0
ViewMutationStage                      0         0              0         0                 0
CacheCleanupExecutor                   0         0              0         0                 0
Repair#1953                            1         3              1         0                 0
MemtableReclaimMemory                  0         0          28251         0                 0
PendingRangeCalculator                 0         0              6         0                 0
AntiCompactionExecutor                 0         0              0         0                 0
SecondaryIndexManagement               0         0              0         0                 0
HintsDispatcher                        0         0             29         0                 0
Native-Transport-Requests              0         0      110953286         0                 0
MigrationStage                         0         0             19         0                 0
PerDiskMemtableFlushWriter_0           0         0          27853         0                 0
Sampler                                0         0              0         0                 0
InternalResponseStage                  0         0          21264         0                 0
AntiEntropyStage                       0         0         350913         0                 0

Message type           Dropped                  Latency waiting in queue (micros)                                    
                                             50%               95%               99%               Max
READ                         0              0.00              0.00              0.00          10090.81
RANGE_SLICE                  0              0.00              0.00          10090.81          10090.81
_TRACE                       0               N/A               N/A               N/A               N/A
HINT                         0              0.00              0.00              0.00              0.00
MUTATION                     0              0.00              0.00              0.00          10090.81
COUNTER_MUTATION             0              0.00              0.00              0.00          10090.81
BATCH_STORE                  0              0.00              0.00              0.00              0.00
BATCH_REMOVE                 0              0.00              0.00              0.00              0.00
REQUEST_RESPONSE             0              0.00              0.00              0.00          12108.97
PAGED_RANGE                  0               N/A               N/A               N/A               N/A
READ_REPAIR                  0              0.00              0.00              0.00              0.00```

Answer 1

Соединения идут к сервису netty, у которого должны быть потоки, равные количеству ядер, даже если у вас есть 10000 подключенных клиентов.Однако Cassandra изначально была разработана с использованием архитектуры поэтапного управления событиями (SEDA), которая находится между асинхронной и полностью поточной моделью.Он создает пулы потоков для обработки различных типов задач.Однако это означает, что в зависимости от конфигурации в вашем yaml может быть много потоков.Например, по умолчанию существует до 128 потоков для собственного транспортного пула, 32 одновременных считывателя, 32 одновременных записывающих устройства, 32 встречных мутации и т. Д., Но если ваш кластер настроен на ssds, они могут быть выше.Имеется в виду несколько таких пулов, которые используют общий пул (отображаемый как SharedWorkers) с SEPExecutor (пул с одним исполнителем).Так что с шипами может быть много созданных, но потоки могут использоваться не часто.

nodetool tpstats предоставит вам подробную информацию о различных пулах и их количестве, что поможет определить, какие потоки используются и используются ли они.Если нет, то вы также можете использовать jstack (используйте того же пользователя, что и процесс cassandra) для сброса следов.Если просмотр этих инструментов, таких как https://fastthread.io/, слишком велик, чтобы его было легче просматривать.

Для чего стоит 32 ГБ памяти и 700 потоков, это не проблема.