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.
Réponses:
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.
la source
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 chaquepostmasterprocessus 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
pour découvrir et
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
la source
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.
la source
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.
la source
Pouvez-vous essayer de désactiver entièrement le swap?
ou quelque chose comme ça - au moins qui validera que c'est l'échange qui est votre problème, et pas autre chose.
la source
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 .
la source
/proc/sys/vm/swappiness.Vous pouvez manuellement définir le swappinness du noyau, que vous pouvez voir
/proc/sys/vm/swappinessou émettre la commandesysctl 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 / modifiervm.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.la source
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
la source
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.
la source
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.la source
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.
la source