Le garbage collector de Go 1.5 est-il prêt pour une gestion de la mémoire à l'échelle du téraoctet ?

Quelle est la vitesse du GC Go 1.5 avec des téraoctets de RAM ?

Contexte :

Java fait face au temps d'interruption du GC A un goulot d'étranglement trop long ne peut pas utiliser efficacement des téraoctets de mémoire. Comme Go GC est optimisé, les gens ne peuvent s'empêcher de se demander s'il peut atteindre un temps d'interruption GC suffisamment court dans un environnement de mémoire de plusieurs téraoctets.

Question :

• Le Go 1.5 GC est-il prêt à gérer des téraoctets de mémoire ?
• Existe-t-il des benchmarks pertinents ?
• Est-il possible d'utiliser un langage avec GC pour gérer une mémoire aussi énorme ?

Réponse :

Points :

• Actuellement, un seul processus Go ne peut pas utiliser des téraoctets de mémoire . La limite maximale sous Linux est de 512 Go, alors que la plus élevée enregistrée lors de tests réels n'était que de 240 Go.
• Dans le mode GC en arrière-plan actuel, la charge de travail du GC est souvent plus critique que le temps d'interruption du GC.
• La charge de travail du GC peut être représentée par le nombre de pointeurs * taux d'allocation / mémoire restante. Dans les applications qui utilisent beaucoup de mémoire, seules les applications avec un plus petit nombre de pointeurs ou moins d'allocations peuvent maintenir la charge de travail du GC à un faible niveau.

Détails :

Le tas Go a une limite de 512 Go, et la taille maximale réelle du tas testée est de 240 Go.

Go 1.5 GC est conçu pour réduire le temps d'interruption du GC, et non pour réduire le travail du GC. Le code est interrompu pendant que le GC analyse la pile et les pointeurs dans les variables globales.

Selon le graphique de la conférence GopherCon 2015, le GC 1.5 a des temps de panne inférieurs dans le benchmark GC avec un tas d'environ 18 Go, comme indiqué :

[Graphique : temps de panne du GC Relation avec le tas taille, montrant des améliorations dans la version 1.5]

Dans les applications réelles, certains temps d'interruption d'origine du GC sont Un rapport de processus de 300 ms est tombé à 4 ms et 20 ms, et une autre application a signalé un temps GC au 95e centile de 279 ms à 10 ms.

Go 1.6 est encore optimisé et place certains travaux en arrière-plan. Le résultat est que même si la taille du tas dépasse 200 Go, le temps d'interruption maximum dans le test est toujours de 20 ms, comme le montre la figure suivante :

[Graphique : 1.6 Le temps GC change avec la taille du tas, atteignant 20 ms environ 180 Go]

Dans la version 1.6, la taille du tas est d'environ 8 Go et l'application alloue environ 150 Mo par minute. 20 ms réduit à 3-4 ms.

Twitch utilise Go pour exécuter son service de chat, et ils signalent que dans la version 1.7, les temps de pause ont été réduits à 1 ms lors de l'exécution simultanée d'un grand nombre de coroutines.

1.8 Sortez l'analyse de la pile de la phase d'arrêt du monde, en gardant la plupart des temps d'interruption inférieurs à 1 ms, même avec de gros tas. Les premiers résultats des tests indiquent de bonnes conditions. Parfois, il existe encore des modèles de code dans l'application qui rendent les coroutines difficiles à interrompre, prolongeant ainsi le temps d'interruption de tous les autres threads, mais dans l'ensemble, le travail en arrière-plan du GC est généralement plus important que le temps d'interruption du GC.

Observations générales :

• La fréquence de collecte du GC dépend de la vitesse d'utilisation de la mémoire.
• La quantité de travail effectuée par chaque collection GC dépend en partie du nombre de pointeurs utilisés. (Y compris les pointeurs dans les tranches, les valeurs d'interface, les chaînes, etc.)

En d'autres termes, même si l'application accède à beaucoup de mémoire, si le nombre de pointeurs est petit (par exemple, elle gère relativement peu de tampon d'octets []) et le taux d'allocation est faible (par exemple, parce que sync.Pool est appliqué pour réutiliser la mémoire dans les scénarios les plus sujets aux débordements de mémoire), le problème GC peut ne pas exister.

Donc, si vous envisagez un gros ordinateur avec des centaines de Go de tas et qu'il est intrinsèquement inadapté au GC, je vous suggère d'envisager les options suivantes :

1. Utiliser C ou similaire L'écriture du langage
2. déplace de grandes quantités de données hors du graphe d'objet, par exemple pour le gérer comme une base de données intégrée (par ex. Bolt), dans un service de base de données externe, ou si vous avez besoin de plus de capacités de mise en cache qu'une base de données, vous pouvez utiliser un outil de mise en cache comme groupcache ou memcache.
3. Exécutez un ensemble de processus qui utilisent un tas plus petit au lieu d'un seul grand processus.
4. Soigneusement prototypé, testé et optimisé pour éviter les problèmes de mémoire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!