performance

J'ai rencontré un petit problème lors de l'éxécution d'un couple de programmes en Python dont l'un "passe" des données à l'autre par l'intermédiaire de "redis". Le problème était un arrêt intempestif du programme recevant les données ce qui entrainait le blocage du programme émetteur.
Après analyse des logs j'ai trouvé des messages d'erreur dans redis.log conseillant d'ajouter :

"vm.overcommit_memory = 1"

dans /etc/sysctl.d en donnant en référence : https://github.com/jemalloc/jemalloc/issues/1328 mais cette page est devenue inaccessible ...

J'ai donc ajouté "vm.overcommit_memory = 1" dans un fichier /etc/sysctl.d/redis.conf et après un petit coup de :
 "sysctl --load=redis.conf" 

et redémarré redis ... depuis mes deux programmes fonctionnent normalement.

Et ... cela n'a pas duré et j'ai toujours des plantages "aléatoires" lors de l'exécution, sans solution pour l'instant alors que sur une autre machine tout fonctionne normalement ... et je ne vois aucune différence entre les versions des programmes, aussi bien Python que Redis.

Après avoir fait un petit voyage à Taïwan et en Corée pour les fêtes de fin d'année je suis quand même revenu …

Et j’ai redémarré mes machines qui ont bénéficié de plus de 3 semaines de repos, mais sur trois machines à la maison une seule a redémarré correctement, celle de madame, mais le pont vers Internet étant HS elle ne permettait pas grand-chose d’utile.
La machine qui sert de pont vers Internet, et qui héberge ce site, a refusé obstinément de démarrer.
En démarrant sur une clef USB j’ai pu constater des dégâts importants : sur 4 disques 2 étaient HS, en principe ces disques sont montés deux par deux en miroir ce qui jusqu’ici m’avait toujours permis de récupérer les données sur le disque « survivant ». Le système, lui aussi sur des disques en miroir (2 x NVME de 1To), n’avait absolument pas souffert et les volumes LVM contenant des machines virtuelles étaient accessibles.
Mais là, les disques « survivants » s’il étaient lisibles ne disposaient pas de la totalité des données, sur une base de données suivie depuis presque 10 ans je n’ai récupéré que les années de 2016 à 2018 ! Le disque qui contenait les sauvegardes était carrément illisible !
J’ai donc du monter de nouveaux disques, recréer les bases de données et les fichiers annexes mais certaines sauvegardes ne se sont pas restaurées complètement et quelques databases MariaDB étaient très incomplètes … et j’ai du les reconstituer en partie à partir de copies faites sur une autre machine pour tester Clickhouse. Cela prend beaucoup de temps mais j’ai fini par remettre le tout en état mais avec une perte d’une partie de l’historique des archives issues de Apache/modsec ou des archives de Suricata.

Au niveau de la base de données elle-même un certain nombre d’utilisateurs étaient absents ou incomplets … je n’arrive pas à comprendre ce phénomène.

J’ai tout de suite commencé la mise en place de sauvegardes des bases de données avec recopie immédiate sur un autre système afin de prendre moins de risques sur les historiques.

Une autre machine avait perdu sa configuration, suspectant un problème avec la pile de maintien j’ai laissé la machine branchée et elle a démarré gentiment le lendemain et fonctionne fort bien, c’est elle qui conservait la copie de certaines données dans une base Clickhouse.

En ce qui concerne les disques « en miroir » j’avais toujours pu récupérer les données sur le disque survivant, même en milieu professionnel. La seule différence ici que j’ai utilisé LVM, le Physical Volume est déclaré sur le miroir et les partitions ne sont pas physiques comme « autrefois » mais juste des Logical Volumes … il va falloir que je réalise quelques tests de reprise en l’absence d’un disque.

Aujourd'hui en analysant les logs de Apache j'ai trouvé un robot OpenAI marquant comme "Referer" https://community.letsencrypt.org et tentant d'accéder à l'Url "/.well-known/acme-challenge/6iKOg35diTyM8rvagvtu3dzO_i1gu75DvMF75dMoC50".

Ce robot chercherait-il à récupérer des informations sur le certificat correspondant ?

Par défaut j'ai bloqué ce type de comportement.

# Microsoft/openAI subnets repérés
4.151.241.0/24
4.196.118.0/24
4.196.198.0/24
13.65.138.0/24
20.27.94.0/24
20.77.178.0/24
20.90.7.0/24
20.97.189.0/24
20.168.78.0/24
20.169.73.0/24
20.169.78.0/24
20.194.1.0/24
20.194.157.0/24
20.117.22.0/24
20.204.24.0/24
20.215.214.0/24
20.215.220.0/24
20.235.75.0/24
23.98.186.0/24
40.84.221.0/24
52.154.22.0/24
52.173.235.0/24
52.187.246.0/24
52.230.164.0/24
68.218.30.0/24
68.221.67.0/24
74.7.36.0/24
74.7.35.0/24
74.7.227.0/24
74.7.175.0/24
74.7.227.0/24
74.7.228.0/24
74.7.230.0/24
74.7.241.0/24
74.7.242.0/24
74.7.244.0/24
104.210.140.0/24
137.135.190.0/24
138.91.30.0/24
137.135.191.0/24
172.182.202.0/24
172.182.214.0/24
172.182.215.0/24
172.183.222.0/24
172.204.16.0/24
172.213.21.0/24

Cette page sera mise à jour assez souvent lors du repérage de nouvelles adresses ...

 

A l'occasion d'un petit test sur la base de données (Clickhouse) qui contient la trace des échanges internet j'ai utilisé le script suivant :

select IPv4NumToString(toUInt32(IP_SRC_ADDR)),
       L4_DST_PORT, count(*)
from flowsv4 
where  FIRST_SWITCHED > toDateTime('2025/11/09')
  and IP_SRC_ADDR not between toString(INET_ATON('192.168.1.0')) and toString(INET_ATON('192.168.3.255'))
  and OUT_BYTES = 0
GROUP BY IP_SRC_ADDR,L4_DST_PORT
HAVING count(*) > 2
order by IP_SRC_ADDR,L4_DST_PORT;

Le résultat m'a surpris : 2599 rows in set (0,017 sec), et entre 12:13 et 12:27 les sous-résaux 45.229.52.0/24 à 45.229.55.0/24 ont totalisé 8983 hits sur le port 443. L'intégralité des adresses (de 0 à 255) de chaque sous-reseau a été utilisée soit 1024 adresses, sans jamais recevoir aucune réponse car j'ai bloqué carrément le pays au niveau du parefeu. 

Il faut purger les journaux de systemd, mais les résultats peuvent surprendre, en effet, une purge est censée supprimer des données mais, parfois, le volume augmente comme dans l'exemple suivant :

Archived and active journals take up 16M in the file system.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal/62d79583138541dbb9fc328e75176ded.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Archived and active journals take up 26.4M in the file system.

Passer de 16Mo à 26,4Mo, j'hésite à appeler cela une "purge".

Le script utilisé est le suivant :

journalctl --disk-usage
journalctl --rotate
journalctl --vacuum-time=2d
journalctl --disk-usage

Qui est lancé tous les jours.

Ma base Clickhouse étant chargée je ne résiste pas au plaisir d'explorer les données stockées par Ntopng depuis quelques années (# 768 millions de rangs)? Ici j'ai recherché les ports les plus scannés de 2019 à 2024, ces ports sont, pour la plupart, fermés par le parefeu et ne donnent lieu à aucune réponse (OUT_BYTES = 0 dans la table). J'ai limité aux 50 ports les plus actifs sur ces 5 années, je n'ai pas pris en compte l'année 2025 par encore terminéé.
Pour des précisions sur Clickhouse voir ICI.

                       Nombre de hits externes par port de 2019 è 2024
┌──PORT─┬──TOTAL─┬─_2019─┬──_2020─┬─_2021─┬──_2022─┬──_2023─┬──_2024─┐
│    23 │ 672462 │ 47538 │  43369 │ 69247 │ 158195 │ 171361 │ 182752 │
│    22 │ 336644 │ 24613 │  24424 │ 42784 │  72004 │  91921 │  80898 │
│  6379 │ 260763 │  3375 │   6233 │ 55849 │  92393 │  56117 │  46796 │
│   445 │ 236658 │ 89599 │  56914 │ 29198 │  24291 │  17462 │  19194 │
│   465 │ 185839 │     0 │ 122256 │ 41240 │  15681 │   3296 │   3366 │
│  8080 │ 177555 │ 16881 │  66484 │ 24526 │  16628 │  24240 │  28796 │
│  3389 │ 115291 │  8802 │   8226 │ 14746 │  22552 │  27726 │  33239 │
│    81 │  90390 │ 15670 │  16857 │ 13336 │  17868 │  14698 │  11961 │
│  1433 │  84800 │  9393 │  15401 │ 18327 │  15102 │  11562 │  15015 │
│   993 │  77752 │  2078 │   3543 │ 21718 │  16301 │  10589 │  23523 │
│  5222 │  75155 │  3596 │  63430 │   960 │   1282 │   2750 │   3137 │
│    25 │  74353 │  7201 │  30668 │   456 │   6051 │     90 │  29887 │
│  5555 │  73875 │  9498 │  12880 │  9241 │  15565 │  13166 │  13525 │
│  8728 │  71342 │   534 │   1618 │  2565 │    167 │   4135 │  62323 │
│   995 │  66375 │   844 │  56869 │  1376 │   1859 │   2372 │   3055 │
│ 23462 │  53179 │    11 │     30 │    16 │      9 │     14 │  53099 │
│  2375 │  53017 │   896 │   2727 │ 12918 │  16207 │   9132 │  11137 │
│  8443 │  49855 │  2301 │   5584 │  5655 │   8872 │  15505 │  11938 │
│  8081 │  45657 │  2476 │   5238 │  5680 │   6272 │   8041 │  17950 │
│  2323 │  45567 │  8044 │   6430 │  4265 │   8727 │   5406 │  12695 │
│  3306 │  41819 │  5209 │   3537 │  3769 │   5634 │   7383 │  16287 │
│  8088 │  40936 │  3799 │   3998 │  3372 │   4289 │   6562 │  18916 │
│  3478 │  39355 │   218 │  26653 │ 11270 │    326 │    365 │    523 │
│  3074 │  37755 │   107 │  26227 │ 10945 │    132 │    156 │    188 │
│  2376 │  36376 │   509 │   1224 │ 10899 │  14420 │   5831 │   3493 │
│  8545 │  35368 │ 13986 │  12932 │  4509 │   2131 │    486 │   1324 │
│  8888 │  34998 │  2933 │   4265 │  4411 │   5131 │   6541 │  11717 │
│   587 │  32878 │  1004 │  14676 │  5647 │   3134 │   3145 │   5272 │
│  8000 │  32639 │  2844 │   5092 │  4337 │   5560 │   5450 │   9356 │
│  3128 │  30750 │  2374 │   3051 │  2917 │   3505 │   6965 │  11938 │
│  2222 │  30082 │  2471 │   2535 │  2829 │   3389 │   5781 │  13077 │
│  5038 │  28042 │  5372 │   9082 │  5929 │   5419 │   1796 │    444 │
│  9200 │  26705 │  1913 │   3874 │  4391 │   4484 │   4681 │   7362 │
│  9000 │  25346 │  3762 │   3452 │  3842 │   4058 │   4500 │   5732 │
│  5900 │  25169 │  3269 │   3763 │  4337 │   3967 │   3800 │   6033 │
│ 27017 │  24771 │  1945 │   2887 │  2819 │   3152 │   3912 │  10056 │
│   631 │  24602 │  4598 │   9952 │  3077 │   1842 │   2278 │   2855 │
│    21 │  24006 │  2518 │   3470 │  3500 │   4318 │   4577 │   5623 │
│ 34852 │  21665 │     8 │     31 │    14 │      6 │  21588 │     18 │
│  4719 │  20882 │    54 │     83 │    49 │     39 │   8038 │  12619 │
│  5060 │  20487 │  1032 │   1899 │  2893 │   4977 │   4913 │   4773 │
│  5432 │  20292 │   872 │   2514 │  3135 │   3498 │   4185 │   6088 │
│  1080 │  20017 │  1617 │   2124 │  1834 │   2713 │   4115 │   7614 │
│  3390 │  19949 │  3702 │   4455 │  3780 │   2562 │   2438 │   3012 │
│    88 │  19742 │  1898 │   4190 │  1651 │   4812 │   3157 │   4034 │
│  3000 │  19173 │  1044 │   5812 │  2403 │   2392 │   3554 │   3968 │
│   489 │  19011 │    45 │    145 │  1479 │   8637 │   8430 │    275 │
│  8090 │  18902 │  1034 │   1650 │  2406 │   3270 │   3819 │   6723 │
│ 32942 │  18449 │    15 │     24 │    15 │      3 │     17 │  18375 │
│  5500 │  17853 │  9560 │   3828 │  1533 │   1218 │    843 │    871 │
└──PORT─┴──TOTAL─┴─_2019─┴──_2020─┴─_2021─┴──_2022─┴──_2023─┴──_2024─┘

Ci-dessous le compte-rendu de Clickhouse pour cette belle requête.

50 rows in set. Elapsed: 5.500 sec. Processed 628.24 million rows, 18.05 GB (114.22 million rows/s., 3.28 GB/s.)
Peak memory usage: 193.52 MiB.

Et pour finir l'ordre SQL lui même :

use local_ntopng;
--
select PORT,sum(CTGEN) AS TOTAL,sum(CT1) as _2019,sum(CT2) as _2020,sum(CT3) as _2021,
		sum(CT4) as _2022,sum(CT5) as _2023,sum(CT6) as _2024
from
(
select YEAR(FIRST_SWITCHED) as ANNEE,L4_DST_PORT as PORT,
	toInt32(count(*)) as CTGEN,toInt32(count(*)) as CT1,toInt32(0) as CT2,toInt32(0) as CT3,
	toInt32(0) as CT4,toInt32(0) as CT5,toInt32(0) as CT6
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2019
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443,465)
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(count(*)),
		toInt32(0),toInt32(0),toInt32(0),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2020
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(count(*)),toInt32(0),toInt32(0),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2021
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(0),toInt32(count(*)),toInt32(0),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2022
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(0),toInt32(0),toInt32(count(*)),toInt32(0)
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2023
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
union all
select YEAR(FIRST_SWITCHED),L4_DST_PORT,toInt32(count(*)),toInt32(0),toInt32(0),
		toInt32(0),toInt32(0),toInt32(0),toInt32(count(*))
from flowsv4
where OUT_BYTES < 1
  and YEAR(FIRST_SWITCHED) = 2024
  and PROTOCOL = 6
  and L4_DST_PORT not in (53,80,443)
  and IP_SRC_ADDR not between '192.168.1.1' and '192.168.3.254'
group by 1,2
)
where PORT < 35000
group by 1
order by 2 desc
limit 50 ;

C'est toujours le port 23 qui tient la tête suivi du port 22 !
Certains ports sont visiblement des "anomalies" avec une grosse fréquentation sur une courte période puis pas grand chose le reste du temps, par exemple le port 23462 ...

J'ai installé une base Clickhouse sur ma machine principale et j'ai positionné l'espace disque sur la nouvelle carte et ses "disques" NVME en RAID 1.

J'ai chargé la table principale de NTOPNG (plus de 766 millions de rangs) et comme premier test j'ai effectué cette statistique sur le port 23, il y en a encore qui tentent ce port ... Comme d'habitude avec Clickhouse le résultat est presque instantané :

60 rows in set. Elapsed: 1.295 sec. Processed 545.39 million rows, 4.86 GB (421.31 million rows/s., 3.76 GB/s.)
Peak memory usage: 8.07 MiB.

Qui a dit que traiter de gros volumes de données c'était long, ici environ 420 millions de rangs sur un total de 768 millions.

J'ai généré avec Openoffice le graphe qui suit :

Note : le "Peak memory usage" est ici assez faible et "passe" très bien sur les 32Gb de la machine, mais j'ai eu quelques ordres SQL incluant de très gros count(distinct(xxx))  sur cette même base tombent car pas assez de mémoire ...

A titre indicatif la description de la carte utilisée est accessible ICI.

Aujourd'hui en lançant une machine virtuelle KVM qui me sert à tester différentes applications, entre autres graphiques, j'ai été surpris de l'absence d'ouverture de la fenêtre graphique ... rien n'était visible ... 
j'ai vérifié la présence de la MV, elle était bien là, l'accès SSH à la machine, c'était OK. 
J'ai donc continué à chercher et j'ai remarqué sur le serveur de MV que :
qemu-system-x86_64 --version 
retournait :
 QEMU emulator version 10.0.0 (Debian 1:10.0.0+ds-2) Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers 
Ah, une version majeure! Qu'est-ce qui a changé ? 
En farfouillant sur internet j'ai trouvé un nouveau paramètre "-display " qui a l'air de correspondre à ce que je cherche. 
Cette version 10 de QEMU apporte des nouveautés mais aussi une suprise : 
La machine se détache complètement et n'ouvre aucun écran graphique alors qu'avant il fallait utiliser l'option "-nographic" pour obtenir ce résultat, tant pis pour ceux qui voulaient utiliser des applications X.
En fait il suffit d'ajouter un paramètre "-display TYPE" au lancement de QEMU. Pour ne pas trop changer les habitudes de chacun les types "sdl" ou "gtk" sont utilisables. il est aussi possible d'utiliser "vnc=nom_display" (non testé). 
Un premier lancement avec "-display gtk" donne un message d'erreur : ... 
Display 'gtk' is not available. Perhaps you want to install qemu-system-gui package? 
Pour pouvoir utiliser les types "sdl" ou "gtk" il faut installer le paquet "qemu-system-gui", un petit coup de :
apt install qemu-system-gui
Règle le problème; ensuite l'option "gtk" marche et la fenêtre de boot apparait, puis l'écran de connextion X fonctionne. 
J'ai ensuite testé l'option "sdl" qui, elle aussi, semble fonctionner comme prévu.
Ces deux options permettent d'utiliser des applications X sans aucun problème.

Le passage du navigateur Opera sous pavillon chinois m’a interpellé, Opera est largement soutenu par les entreprises chinoises et l’on peut se poser des questions sur la pertinence de « quitter » ce navigateur. L'ancien développeur d’Opera développe actuellement un nouveau browser nommé Vivaldi ...

1. Le contexte de l'acquisition par une entreprise chinoise (Alibaba):

• L'acquisition par Alibaba a été le facteur clé. Cette acquisition a permis à Opera d'être intégré au vaste écosystème Alibaba, ce qui a entraîné plusieurs changements significatifs, et pas toujours dans le bon sens;

2. Pourquoi Vivaldi peut être perçu comme un choix plus intéressant :

Bien que Opera soit toujours utilisé par beaucoup, je l’ai remplacé par Vivaldi, voici quelques raisons qui ont amené ce choix :

• Vivaldi est souvent considéré comme étant plus axé sur le confort de l'utilisateur et l'accessibilité. Il propose des options de personnalisation plus poussées, notamment:

  • Amélioration de la lisibilité : Le design est conçu pour être plus lisible sur différents écrans et avec différentes tailles de police.

  • Options d'affichage avancées : Vivaldi offre des options pour afficher les éléments importants (comme les liens et les informations) en évidence, ce qui peut améliorer l'expérience utilisateur pour certains utilisateurs.

  • Compatibilité plus large : Vivaldi a été conçu pour fonctionner de manière optimale sur une gamme plus large d’appareils, y compris les ordinateurs portables et les appareils mobiles, que certains utilisateurs de Opera trouvent « pénibles ».

• Interface utilisateur plus intuitive : il semble que certains utilisateurs trouvent que l'interface de Vivaldi est plus intuitive, avec un système de navigation plus "direct" et facile à comprendre. Cela peut être lié à la façon dont il a été conçu pour des utilisateurs plus expérimentés avec les navigateurs web.
• Moins d’encombrement: Il semble que Vivaldi a moins de publicités intégrées par défaut, ce qui peut améliorer l'expérience utilisateur.
• Indépendance : la présence d'Alibaba n'est probablement pas neutre.

3. La perception et la popularité :

• Popularité relative : Bien que Opera ait une base d'utilisateurs plus importante, Vivaldi semble plus populaire auprès des développeurs de logiciels et des utilisateurs qui apprécient sa personnalisation et son focus sur l’accessibilité.

• Communauté : La communauté Vivaldi est plus active et a un sentiment de communauté plus fort que celui de Opera.

Conclusion provisoire, (ou définitive ?) :

Il n'y a pas une "préférence" unique, mais plutôt un ensemble de facteurs qui devraient conduire la plupart des utilisateurs à préférer Vivaldi. L'acquisition par Alibaba a été le facteur principal, mais la conception et l'approche de Vivaldi devraient attirer les utilisateurs qui recherchent un navigateur plus flexible et personnalisable, en particulier pour les utilisateurs sensibles aux aspects de lisibilité et d’accessibilité.