Oui je comprends, c'est un des rapports en ce sens à ma connaissance dans notre discourse.
On a pas ou très rarement de report sur les perfs, et quand c'est le cas, 9 fois sur 10 c'est un souci de parser ou de scenario.
Mais l'équipe était prête à investiguer et le sera toujours. Again, on a des setups à plusieurs dizaines de millions d'events per day et ca ne pose aucun de souci. Jette un oeil sur le post de scaling, on atteind des perf ahurissantes sur des milliards de lignes de logs, qui ne sont clairement pas compatibles avec ce type de souci.
Je ne suis pas spécialiste du point mais à mon avis, ca vaudrait le coup de tester avec un F2B désactivé pour éviter la compétition en read sur la même log source. Le kernel pourrait faire des locks a chaque ajout de ligne.
[^] # Re: crowdsec
Posté par Philippe_CrowdSec . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 4.
Oui je comprends, c'est un des rapports en ce sens à ma connaissance dans notre discourse.
On a pas ou très rarement de report sur les perfs, et quand c'est le cas, 9 fois sur 10 c'est un souci de parser ou de scenario.
Mais l'équipe était prête à investiguer et le sera toujours. Again, on a des setups à plusieurs dizaines de millions d'events per day et ca ne pose aucun de souci. Jette un oeil sur le post de scaling, on atteind des perf ahurissantes sur des milliards de lignes de logs, qui ne sont clairement pas compatibles avec ce type de souci.
Je ne suis pas spécialiste du point mais à mon avis, ca vaudrait le coup de tester avec un F2B désactivé pour éviter la compétition en read sur la même log source. Le kernel pourrait faire des locks a chaque ajout de ligne.