Le scénario actuel est le suivant : les performances de la machine sont telles que le CPU est très faible. J'ai oublié le numéro de modèle du i7. nb signifie qu'il y a très peu d'opérations CPU pendant l'interrogation. Visualisez-le via htop. Mais la mémoire n'est pas bonne, elle n'est que de 8 g, et la mémoire sera certainement augmentée à l'avenir. Le disque dur est également un disque mécanique ordinaire et sera remplacé plus tard, mais c'est pour plus tard. Ce que je peux ressentir maintenant, c'est que lorsque les données de requête sont supérieures à 100 000, le goulot d'étranglement apparaît sur io, io est verrouillé et la mémoire est bloquée. l'utilisation est également pleine. En conséquence, d'autres opérations sont bloquées. Même si cet impact est faible, il se reflète dans le long temps d'attente des pages sur le Web.
Actuellement, les optimisations suivantes ont été effectuées :
1. Ajustez la valeur de la taille de la pile Linux.
2. Créez un index.
3. Mettez certaines données populaires dans une collection distincte qui n'a pas été modifiée dans un passé récent (un mois).
Grâce aux trois optimisations ci-dessus, la situation sera meilleure. Mais il y aura toujours des problèmes. Lorsqu'il y a plusieurs conditions dans la requête, l'index sera invalide. Les choses sont toujours aussi mauvaises.
Donc, très contradictoire. Comment pouvons-nous bien le gérer ? Donc, s’il existe un autre serveur avec la même configuration, cette situation peut-elle être résolue grâce à des opérations telles que le sharding ?

Merci