Собираем NetFlow дёшево и сердито
TL;DR: автор собрал коллектор NetFlow/sFlow из GoFlow, Kafka, ClickHouse, Grafana и костыля на Go.
Эксплуататор
TL;DR: автор собрал коллектор NetFlow/sFlow из GoFlow, Kafka, ClickHouse, Grafana и костыля на Go.
Во время сравнения нового серверного чипа Centriq от Qualcomm с имеющимися в наличии Intel Xeon поколения Skylake мною была замечена странная штука: производительность шифра ChaCha20-Poly1305 плохо масштабируется при добавлении ядер. Один поток работал на скорости примерно 2,89 Гбайт/с, а на 24 ядрах и при 48 потоках сумарная производительность составила всего лишь 35 Гбайт/с.
Неплохо, конечно, но я ожидал увидеть что-то вроде 69 Гбайт/с. 35 Гбайт/с это всего лишь 1,46 Гбайт/с на ядро, или около 50 % от производительности одного ядра. AES-GCM масштабируется в тех же условиях гораздо лучше, до примерно 80 % производительности одного ядра, что объясняется способностью процессора повышать частоту при нагрузке на одно ядро.
Метод масштабирования TCP-серверов, как правило, очевиден. Начни с одного процесса, когда будет нужно — просто добавь ещё. Так делают многие приложения, включая HTTP-серверы типа Apache, NGINX или Lighttpd.
Увеличение количества обслуживающих процессов это отличный метод решения проблемы использования всего одного ядра CPU, правда, ценой возникновения других проблем.