Le serveur Linux n'utilise que 60% de la mémoire, puis échange

J'ai un serveur Linux qui exécute notre système de sauvegarde bacula. La machine grince comme une folle parce qu'elle devient lourde à échanger. Le problème, c'est qu'il n'utilise que 60% de sa mémoire physique!

Voici la sortie de free -m:

free -m
             total       used       free     shared    buffers     cached
Mem:          3949       2356       1593          0          0          1
-/+ buffers/cache:       2354       1595
Swap:         7629       1804       5824

et quelques exemples de sortie de vmstat 1:

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2 1843536 1634512      0   4188   54   13  2524   666    2    1  1  1 89  9  0
 1 11 1845916 1640724      0    388 2700 4816 221880  4879 14409 170721  4  3 63 30  0
 0  9 1846096 1643952      0      0 4956  756 174832   804 12357 159306  3  4 63 30  0
 0 11 1846104 1643532      0      0 4916  540 174320   580 10609 139960  3  4 64 29  0
 0  4 1846084 1640272      0   2336 4080  524 140408   548 9331 118287  3  4 63 30  0
 0  8 1846104 1642096      0   1488 2940  432 102516   457 7023 82230  2  4 65 29  0
 0  5 1846104 1642268      0   1276 3704  452 126520   452 9494 119612  3  5 65 27  0
 3 12 1846104 1641528      0    328 6092  608 187776   636 8269 113059  4  3 64 29  0
 2  2 1846084 1640960      0    724 5948    0 111480     0 7751 116370  4  4 63 29  0
 0  4 1846100 1641484      0    404 4144 1476 125760  1500 10668 105358  2  3 71 25  0
 0 13 1846104 1641932      0      0 5872  828 153808   840 10518 128447  3  4 70 22  0
 0  8 1846096 1639172      0   3164 3556  556 74884   580 5082 65362  2  2 73 23  0
 1  4 1846080 1638676      0    396 4512   28 50928    44 2672 38277  2  2 80 16  0
 0  3 1846080 1628808      0   7132 2636    0 28004     8 1358 14090  0  1 78 20  0
 0  2 1844728 1618552      0  11140 7680    0 12740     8  763 2245  0  0 82 18  0
 0  2 1837764 1532056      0 101504 2952    0 95644    24  802 3817  0  1 87 12  0
 0 11 1842092 1633324      0   4416 1748 10900 143144 11024 6279 134442  3  3 70 24  0
 2  6 1846104 1642756      0      0 4768  468 78752   468 4672 60141  2  2 76 20  0
 1 12 1846104 1640792      0    236 4752  440 140712   464 7614 99593  3  5 58 34  0
 0  3 1846084 1630368      0   6316 5104    0 20336     0 1703 22424  1  1 72 26  0
 2 17 1846104 1638332      0   3168 4080 1720 211960  1744 11977 155886  3  4 65 28  0
 1 10 1846104 1640800      0    132 4488  556 126016   584 8016 106368  3  4 63 29  0
 0 14 1846104 1639740      0   2248 3436  428 114188   452 7030 92418  3  3 59 35  0
 1  6 1846096 1639504      0   1932 5500  436 141412   460 8261 112210  4  4 63 29  0
 0 10 1846104 1640164      0   3052 4028  448 147684   472 7366 109554  4  4 61 30  0
 0 10 1846100 1641040      0   2332 4952  632 147452   664 8767 118384  3  4 63 30  0
 4  8 1846084 1641092      0    664 4948  276 152264   292 6448 98813  5  5 62 28  0

De plus, la sortie de top triée par temps CPU semble soutenir la théorie selon laquelle l'échange est ce qui embourbe le système:

top - 09:05:32 up 37 days, 23:24,  1 user,  load average: 9.75, 8.24, 7.12
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  1.4%sy,  0.0%ni, 76.1%id, 20.6%wa,  0.1%hi,  0.2%si,  0.0%st
Mem:   4044632k total,  2405628k used,  1639004k free,        0k buffers
Swap:  7812492k total,  1851852k used,  5960640k free,      436k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 4174 root      17   0 63156  176   56 S    8  0.0   2138:52  35,38 bacula-fd                                                                                                                            
 4185 root      17   0 63352  284  104 S    6  0.0   1709:25  28,29 bacula-sd                                                                                                                            
  240 root      15   0     0    0    0 D    3  0.0 831:55.19 831:55 kswapd0                                                                                                                              
 2852 root      10  -5     0    0    0 S    1  0.0 126:35.59 126:35 xfsbufd                                                                                                                              
 2849 root      10  -5     0    0    0 S    0  0.0 119:50.94 119:50 xfsbufd                                                                                                                              
 1364 root      10  -5     0    0    0 S    0  0.0 117:05.39 117:05 xfsbufd                                                                                                                              
   21 root      10  -5     0    0    0 S    1  0.0  48:03.44  48:03 events/3                                                                                                                             
 6940 postgres  16   0 43596    8    8 S    0  0.0  46:50.35  46:50 postmaster                                                                                                                           
 1342 root      10  -5     0    0    0 S    0  0.0  23:14.34  23:14 xfsdatad/4                                                                                                                           
 5415 root      17   0 1770m  108   48 S    0  0.0  15:03.74  15:03 bacula-dir                                                                                                                           
   23 root      10  -5     0    0    0 S    0  0.0  13:09.71  13:09 events/5                                                                                                                             
 5604 root      17   0 1216m  500  200 S    0  0.0  12:38.20  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  580  248 S    0  0.0  11:58.00  11:58 java

Voici le même tri par taille d'image de mémoire virtuelle:

top - 09:08:32 up 37 days, 23:27,  1 user,  load average: 8.43, 8.26, 7.32
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  3.4%sy,  0.0%ni, 62.2%id, 30.2%wa,  0.2%hi,  0.3%si,  0.0%st
Mem:   4044632k total,  2404212k used,  1640420k free,        0k buffers
Swap:  7812492k total,  1852548k used,  5959944k free,      100k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 5415 root      17   0 1770m   56   44 S    0  0.0  15:03.78  15:03 bacula-dir                                                                                                                           
 5604 root      17   0 1216m  492  200 S    0  0.0  12:38.30  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  476  200 S    0  0.0  11:58.20  11:58 java                                                                                                                                 
 4598 root      16   0  117m   44   44 S    0  0.0   0:13.37   0:13 eventmond                                                                                                                            
 9614 gdm       16   0 93188    0    0 S    0  0.0   0:00.30   0:00 gdmgreeter                                                                                                                           
 5527 root      17   0 78716    0    0 S    0  0.0   0:00.30   0:00 gdm                                                                                                                                  
 4185 root      17   0 63352  284  104 S   20  0.0   1709:52  28,29 bacula-sd                                                                                                                            
 4174 root      17   0 63156  208   88 S   24  0.0   2139:25  35,39 bacula-fd                                                                                                                            
10849 postgres  18   0 54740  216  108 D    0  0.0   0:31.40   0:31 postmaster                                                                                                                           
 6661 postgres  17   0 49432    0    0 S    0  0.0   0:03.50   0:03 postmaster                                                                                                                           
 5507 root      15   0 47980    0    0 S    0  0.0   0:00.00   0:00 gdm                                                                                                                                  
 6940 postgres  16   0 43596   16   16 S    0  0.0  46:51.39  46:51 postmaster                                                                                                                           
 5304 postgres  16   0 40580  132   88 S    0  0.0   6:21.79   6:21 postmaster                                                                                                                           
 5301 postgres  17   0 40448   24   24 S    0  0.0   0:32.17   0:32 postmaster                                                                                                                           
11280 root      16   0 40288   28   28 S    0  0.0   0:00.11   0:00 sshd                                                                                                                                 
 5534 root      17   0 37580    0    0 S    0  0.0   0:56.18   0:56 X                                                                                                                                    
30870 root      30  15 31668   28   28 S    0  0.0   1:13.38   1:13 snmpd                                                                                                                                
 5305 postgres  17   0 30628   16   16 S    0  0.0   0:11.60   0:11 postmaster                                                                                                                           
27403 postfix   17   0 30248    0    0 S    0  0.0   0:02.76   0:02 qmgr                                                                                                                                 
10815 postfix   15   0 30208   16   16 S    0  0.0   0:00.02   0:00 pickup                                                                                                                               
 5306 postgres  16   0 29760   20   20 S    0  0.0   0:52.89   0:52 postmaster                                                                                                                           
 5302 postgres  17   0 29628   64   32 S    0  0.0   1:00.64   1:00 postmaster

J'ai essayé de régler le swappinessparamètre du noyau sur des valeurs élevées et basses, mais rien ne semble changer le comportement ici. Je ne sais pas ce qui se passe. Comment puis-je savoir ce qui cause cela?

Mise à jour: Le système est un système entièrement 64 bits, il ne devrait donc pas être question de limitations de mémoire en raison de problèmes 32 bits.

Update2: Comme je l'ai mentionné dans la question d'origine, j'ai déjà essayé de régler la permutabilité à toutes sortes de valeurs, y compris 0. Le résultat est toujours le même, avec environ 1,6 Go de mémoire restant inutilisé.

Update3: Ajout de la sortie supérieure aux informations ci-dessus.

Les performances de Bacula dépendent fortement de la base de données. Probablement, c'est postgresql qui tue votre serveur. La moyenne de charge élevée et le pourcentage assez important de temps processeur passé en attente indiquent clairement qu'il attend les E / S disque ... Et c'est ce que fait PostgreSQL. Pour chaque fichier de votre sauvegarde, définissez au moins une instruction UPDATE. Ne vous inquiétez pas de l'échange.

Réglez l'installation de PostgreSQL. Donner éventuellement à chaque base de données (ou même tables) leurs propres disques / ensembles de raid pour répartir les E / S. Vous pouvez forcer PostgreSQL à utiliser des écritures aynschrones si ce n'est pas déjà fait ... Bien que cela permette d'intégrer l'intégrité de la base de données pour les performances d'écriture. Boostez la mémoire partagée disponible pour PostgreSQL. Cela allégera au moins une grande partie de la lecture sur la base de données. Si vous ne l'avez jamais fait, exécutez également VACCUM ANALYZE sur la base de données Bacula pour donner à l'optimiseur de requête quelque chose à utiliser.

De loin, le point le plus faible de Bacula est les dépendances à la base de données (et la mort cérébrale de certaines d'entre elles ...) Exécutez une purge d'une grande sauvegarde récente et notez combien de temps (des heures souvent) il faut pour exécuter quelques dizaines de millions de requêtes. .. Bacula aime relativement peu de gros fichiers, sinon c'est un chien.

Vous êtes lié aux E / S. Votre système est un petit radeau de sauvetage, battu dans une mer orageuse de houles de pagination tampon / cache / VM de 100 pieds de haut.

Sensationnel. Juste wow. Vous déplacez environ 100 Mo / s sur vos E / S, vous avez dépassé 50% du temps CPU en attente d'E / S et vous avez 4 Go de RAM. La contre-pression sur la VM de ce serveur doit être énorme. Dans des circonstances «normales», alors que le système commence à mettre en mémoire tampon / cache, toute RAM libre que vous aviez va être consommée vivante en moins de 40 secondes .

Serait-il possible de publier les paramètres depuis /proc/sys/vm? Cela fournirait un aperçu de ce que votre noyau pense être "normal".

Ces postmasterprocessus indiquent également que vous exécutez PostgreSQL en arrière-plan. Est-ce normal pour votre configuration? PostgreSQL dans une configuration par défaut utilisera très peu de RAM, mais une fois qu'il est réglé à nouveau pour la vitesse, il peut rapidement mâcher 25% à 40% de votre RAM disponible. Je ne peux donc que deviner, étant donné le nombre d'entre eux dans la sortie, vous exécutez une sorte de base de données de production pendant que vous exécutez des sauvegardes. Cela n'augure rien de bon. Pouvez-vous donner plus d'informations sur la raison pour laquelle il fonctionne? Quelle est la taille du paramètre de mémoire partagée pour touspostmasterprocessus? Serait-il possible d'arrêter le service ou de reconfigurer temporairement la base de données pour utiliser moins de connexions / tampons pendant l'exécution des sauvegardes? Cela aidera à réduire la pression sur les E / S déjà sollicitées et la RAM libre. Gardez à l'esprit que chaque postmasterprocessus consomme de la RAM au-delà de ce que la base de données utilise pour la mise en cache interne. Ainsi, lorsque vous ajustez les paramètres de la mémoire, faites attention à ceux qui sont «partagés» et lesquels sont «par processus» .

Si vous utilisez PostgreSQL dans le cadre de votre processus de sauvegarde, essayez de le régler à nouveau pour accepter uniquement le nombre minimum de connexions , et assurez-vous de réduire vos paramètres par processus à quelque chose de raisonnable (seulement quelques mégaoctets chacun). L'inconvénient est que PostgreSQL se répandra sur le disque s'il ne peut pas fonctionner avec l'ensemble de données en RAM comme il le souhaite, ce qui augmentera en fait les E / S de votre disque , alors ajustez soigneusement.

X11 en soi ne prend pas beaucoup de mémoire, mais une session de bureau complète peut consommer plusieurs mégaoctets. Déconnectez toutes les sessions actives que vous avez et exécutez votre connexion à partir de la console ou via SSH.

Pourtant, je ne pense pas que ce soit entièrement un problème de mémoire. Si vous êtes meilleur que 50% d'E / S, attendez pendant de longues périodes (et que vous publiez des chiffres qui touchent aux années 70), le goulot d'étranglement qui en résultera finira par écraser le reste du système. Tout comme Dark Vador écrase les cous.

Pour combien de threads de vidage êtes-vous configuré? Utilisation

cat /proc/sys/vm/nr_pdflush_threads

pour découvrir et

echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf

pour le définir sur un seul thread. Notez que la dernière commande le charge en permanence au redémarrage. Voir 1 ou 2 n'est pas inhabituel. Si vous avez plusieurs cœurs ou beaucoup de capacité de broche / bus pour les E / S, vous voudrez les heurter (légèrement). Plus de threads de vidage = plus d'activité d'E / S, mais aussi plus de temps CPU passé en attente d'E / S.

Est-ce la valeur par défaut ou l'avez-vous dépassée? Si vous l'avez heurtée, avez-vous envisagé de diminuer le nombre pour réduire la pression sur les opérations d'E / S? Ou avez-vous un grand nombre de broches et de canaux avec lesquels travailler, dans quel cas, avez-vous envisagé d' augmenter le nombre de threads de vidage?

PS vous souhaitez définir la permutation sur les valeurs inférieures, et non sur les valeurs supérieures, pour empêcher la permutation. Valeur la plus élevée = 100 = permutez comme un fou quand cela vous convient, valeur la plus faible = 0 = essayez de ne pas permuter du tout

Si vous regardez les blocs lus par seconde (bi) sous IO, cela éclipse l'activité de swap de plusieurs ordres de grandeur. Je ne pense pas que l'utilisation du swap soit à l'origine de la destruction de votre disque, je pense que vous avez quelque chose en cours d'exécution sur la boîte qui provoque simplement beaucoup d'activité sur le disque (lectures).

J'examinerais les applications en cours d'exécution et verrais si vous pouvez trouver le coupable.

Vérifiez si ce lien répond à certaines de vos questions. Je vois régulièrement la pagination Linux (pas l'échange) sur la mémoire bien avant une utilisation à 60%. Il s'agit d'un élément attendu de son réglage de la mémoire:

http://www.sheepguardingllama.com/?p=2252

Mais votre manque de tampons / cache m'inquiète. Cela semble très inhabituel. Je pense donc que quelque chose de plus ne va pas.

Pouvez-vous essayer de désactiver entièrement le swap?

swapoff /dev/hdb2

ou quelque chose comme ça - au moins qui validera que c'est l'échange qui est votre problème, et pas autre chose.

Par défaut, la permutation est définie sur 60.

chat / proc / sys / vm / swappiness 60

Swappiness est un noyau utilisé pour ajuster à quel point le noyau favorise l'échange sur la RAM; un swappiness élevé signifie que le noyau échangera beaucoup, et un swappiness faible signifie que le noyau essaiera de ne pas utiliser l'espace de swap.

Nous pouvons modifier cette modification de la valeur de vm.swappiness dans /etc/sysctl.conf .

Vous pouvez manuellement définir le swappinness du noyau, que vous pouvez voir /proc/sys/vm/swappinessou émettre la commande sysctl vm.swappiness. Le swappiness est un paramètre du noyau qui détermine combien le swap est utilisé.

En définissant, sudo sysctl vm.swappiness=0vous désactivez effectivement la partition de swap. Pour effectuer cette modification permanente , vous pouvez ajouter / modifier vm.swappiness=0dans /etc/sysctl.conf. Vous devriez voir ce qui est une bonne valeur pour vous. Personnellement, je l'ai configuré vm.swappiness=10, 60 étant la valeur par défaut.

Une autre chose que vous voudrez peut-être examiner est votre file d'attente d'exécution du noyau et les processus ininterrompus (les colonnes «r» et «b» dans vmstat) sont un indicateur que le système est parfois saturé. D'un autre côté, ne confondez pas la saturation avec l'utilisation ... le vrai problème peut être une pile de processus affamée contre le noyau saturé :-(

Vous pouvez également exécuter «pmap -x [PID]» pour obtenir des détails supplémentaires sur la mémoire de certains des processus les plus gourmands. Je te souhaite bonne chance!

Mat

Peut-être que vous avez des processus de courte durée qui utilisent beaucoup de mémoire, puis quittez avant d'avoir la chance de les remarquer.

Ce serait cohérent avec ce que vous voyez de toute façon.

Avez-vous étudié les problèmes liés au cache d'inode? slabtopdevrait au moins vous donner un point de départ si vous rencontrez quelque chose comme ça.

Alors que votre système est en 64 bits, le système peut ne pas être en mesure d'adresser la totalité de la mémoire disponible. Il s'agit d'une limitation du chipset. Par exemple, le Mac mini de la génération précédente "prend en charge" 4 Go de RAM, mais seulement 3,3 Go étaient réellement adressables.