Frage Ungewöhnlich hohe Cache-Nutzung


Problem

Eine CentOS-Maschine mit Kernel 2.6.32 und 128 GB physikalischem RAM ist vor einigen Tagen in Schwierigkeiten geraten. Der verantwortliche Systemadministrator teilt mir mit, dass die PHP-FPM-Anwendung nicht mehr zeitnah auf Anfragen reagiert hat, weil sie ausgetauscht wurde und sie gesehen hat free dass fast keine Erinnerung mehr übrig war, entschied er sich, den Rechner neu zu starten.

Ich weiß, dass freier Speicher auf Linux ein verwirrendes Konzept sein kann und ein Neustart vielleicht die falsche Sache war. Der genannte Administrator macht jedoch die PHP-Anwendung (für die ich verantwortlich bin) verantwortlich und weigert sich, weiter zu untersuchen.

Was ich selbst herausfinden könnte, ist folgendes:

  • Vor dem Neustart betrug der freie Speicher (inkl. Puffer und Cache) nur ein paar hundert MB.
  • Vor dem Neustart, /proc/meminfo eine Plattenspeicherbelegung von rund 90 GB gemeldet (ja, GB).
  • Nach dem Neustart lag der freie Speicher bei 119 GB und ging innerhalb einer Stunde auf rund 100 GB zurück, als die PHP-FPM-Mitarbeiter (etwa 600) wieder zum Leben erwachten und jeweils zwischen 30 und 40 MB in der RES-Spalte in top (was seit Monaten so ist und angesichts der Art der PHP-Anwendung durchaus sinnvoll ist). Es gibt nichts anderes in der Prozessliste, das eine ungewöhnliche oder nennenswerte Menge an RAM verbraucht.
  • Nach dem Neustart lag der Slab-Speicher bei etwa 300 MB

Wenn das System seither überwacht wird, steigt vor allem der Slab-Speicher in einer geraden Linie mit einer Rate von etwa 5 GB pro Tag. Freier Speicher wie von free und /proc/meminfo nimmt mit der gleichen Rate ab. Die Platte liegt derzeit bei 46 GB. Gemäß slabtop das meiste davon wird benutzt für dentry Einträge:

Freier Speicher:

free -m
             total       used       free     shared    buffers     cached
Mem:        129048      76435      52612          0        144       7675
-/+ buffers/cache:      68615      60432
Swap:         8191          0       8191

Meminfo:

cat /proc/meminfo
MemTotal:       132145324 kB
MemFree:        53620068 kB
Buffers:          147760 kB
Cached:          8239072 kB
SwapCached:            0 kB
Active:         20300940 kB
Inactive:        6512716 kB
Active(anon):   18408460 kB
Inactive(anon):    24736 kB
Active(file):    1892480 kB
Inactive(file):  6487980 kB
Unevictable:        8608 kB
Mlocked:            8608 kB
SwapTotal:       8388600 kB
SwapFree:        8388600 kB
Dirty:             11416 kB
Writeback:             0 kB
AnonPages:      18436224 kB
Mapped:            94536 kB
Shmem:              6364 kB
Slab:           46240380 kB
SReclaimable:   44561644 kB
SUnreclaim:      1678736 kB
KernelStack:        9336 kB
PageTables:       457516 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    72364108 kB
Committed_AS:   22305444 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      480164 kB
VmallocChunk:   34290830848 kB
HardwareCorrupted:     0 kB
AnonHugePages:  12216320 kB
HugePages_Total:    2048
HugePages_Free:     2048
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        5604 kB
DirectMap2M:     2078720 kB
DirectMap1G:    132120576 kB

Platte:

slabtop --once
Active / Total Objects (% used)    : 225920064 / 226193412 (99.9%)
 Active / Total Slabs (% used)      : 11556364 / 11556415 (100.0%)
 Active / Total Caches (% used)     : 110 / 194 (56.7%)
 Active / Total Size (% used)       : 43278793.73K / 43315465.42K (99.9%)
 Minimum / Average / Maximum Object : 0.02K / 0.19K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
221416340 221416039   3%    0.19K 11070817       20  44283268K dentry                 
1123443 1122739  99%    0.41K 124827        9    499308K fuse_request           
1122320 1122180  99%    0.75K 224464        5    897856K fuse_inode             
761539 754272  99%    0.20K  40081       19    160324K vm_area_struct         
437858 223259  50%    0.10K  11834       37     47336K buffer_head            
353353 347519  98%    0.05K   4589       77     18356K anon_vma_chain         
325090 324190  99%    0.06K   5510       59     22040K size-64                
146272 145422  99%    0.03K   1306      112      5224K size-32                
137625 137614  99%    1.02K  45875        3    183500K nfs_inode_cache        
128800 118407  91%    0.04K   1400       92      5600K anon_vma               
 59101  46853  79%    0.55K   8443        7     33772K radix_tree_node        
 52620  52009  98%    0.12K   1754       30      7016K size-128               
 19359  19253  99%    0.14K    717       27      2868K sysfs_dir_cache        
 10240   7746  75%    0.19K    512       20      2048K filp  

VFS-Cachedruck:

cat /proc/sys/vm/vfs_cache_pressure
125

Swappiness:

cat /proc/sys/vm/swappiness
0

Ich weiß, dass ungenutzter Speicher ungenutzter Speicher ist, daher sollte dies nicht unbedingt eine schlechte Sache sein (besonders, wenn 44 GB als SReclaimable angegeben sind). Offenbar hatte die Maschine jedoch trotzdem Probleme, und ich fürchte, das wird in ein paar Tagen wieder passieren, wenn Slab 90 GB überschreitet.

Fragen

Ich habe diese Fragen:

  • Habe ich recht, wenn ich daran denke, dass der Slab-Speicher immer physikalischer RAM ist und die Zahl bereits vom MemFree-Wert abgezogen wird?
  • Ist eine so hohe Anzahl an Dentry-Einträgen normal? Die PHP-Anwendung hat Zugriff auf ca. 1,5 M-Dateien, die meisten davon sind jedoch Archive und werden überhaupt nicht für den normalen Web-Verkehr genutzt.
  • Was könnte eine Erklärung für die Tatsache sein, dass die Anzahl der zwischengespeicherten Inodes viel niedriger ist als die Anzahl der zwischengespeicherten Dentries, sollten sie nicht irgendwie zusammenhängen?
  • Wenn das System in Speicherprobleme gerät, sollte der Kernel einige der Dentries nicht automatisch freigeben? Was könnte ein Grund sein, dass das nicht passiert?
  • Gibt es eine Möglichkeit, in den Dentry-Cache zu schauen, um zu sehen, was all dieser Speicher ist (d. H. Welche Pfade werden zwischengespeichert)? Vielleicht deutet dies auf eine Art von Speicherverlust, Symlink-Schleife oder tatsächlich auf etwas hin, was die PHP-Anwendung falsch macht.
  • Der PHP-Anwendungscode sowie alle Asset-Dateien werden über GlusterFS-Netzwerk-Dateisystem gemounted, könnte das etwas damit zu tun haben?

Bitte beachten Sie, dass ich als root nur als normaler Benutzer nicht ermitteln kann und dass der Administrator nicht helfen will. Er wird nicht einmal das Typische laufen lassen echo 2 > /proc/sys/vm/drop_caches Testen Sie, ob der Slab-Speicher tatsächlich wiederherstellbar ist.

Irgendwelche Einsichten darüber, was vor sich gehen könnte und wie ich weiter untersuchen könnte, wären sehr willkommen.

Aktualisierung

Einige weitere Diagnoseinformationen:

Halterungen:

cat /proc/self/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=66063000k,nr_inodes=16515750,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/dev/mapper/sysvg-lv_root / ext4 rw,relatime,barrier=1,data=ordered 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0
tmpfs /phptmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0
tmpfs /wsdltmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /cgroup/cpu cgroup rw,relatime,cpu 0 0
cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0
/etc/glusterfs/glusterfs-www.vol /var/www fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0
/etc/glusterfs/glusterfs-upload.vol /var/upload fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
172.17.39.78:/www /data/www nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78 0 0

Montageinfo:

cat /proc/self/mountinfo
16 21 0:3 / /proc rw,relatime - proc proc rw
17 21 0:0 / /sys rw,relatime - sysfs sysfs rw
18 21 0:5 / /dev rw,relatime - devtmpfs devtmpfs rw,size=66063000k,nr_inodes=16515750,mode=755
19 18 0:11 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
20 18 0:16 / /dev/shm rw,relatime - tmpfs tmpfs rw
21 1 253:1 / / rw,relatime - ext4 /dev/mapper/sysvg-lv_root rw,barrier=1,data=ordered
22 16 0:15 / /proc/bus/usb rw,relatime - usbfs /proc/bus/usb rw
23 21 8:1 / /boot rw,relatime - ext4 /dev/sda1 rw,barrier=1,data=ordered
24 21 0:17 / /phptmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777
25 21 0:18 / /wsdltmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777
26 16 0:19 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc none rw
27 21 0:20 / /cgroup/cpuset rw,relatime - cgroup cgroup rw,cpuset
28 21 0:21 / /cgroup/cpu rw,relatime - cgroup cgroup rw,cpu
29 21 0:22 / /cgroup/cpuacct rw,relatime - cgroup cgroup rw,cpuacct
30 21 0:23 / /cgroup/memory rw,relatime - cgroup cgroup rw,memory
31 21 0:24 / /cgroup/devices rw,relatime - cgroup cgroup rw,devices
32 21 0:25 / /cgroup/freezer rw,relatime - cgroup cgroup rw,freezer
33 21 0:26 / /cgroup/net_cls rw,relatime - cgroup cgroup rw,net_cls
34 21 0:27 / /cgroup/blkio rw,relatime - cgroup cgroup rw,blkio
35 21 0:28 / /var/www rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-www.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
36 21 0:29 / /var/upload rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-upload.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
37 21 0:30 / /var/lib/nfs/rpc_pipefs rw,relatime - rpc_pipefs sunrpc rw
39 21 0:31 / /data/www rw,relatime - nfs 172.17.39.78:/www rw,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78

GlusterFS-Konfiguration:

cat /etc/glusterfs/glusterfs-www.vol
volume remote1
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.71
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
    # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote2
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.72
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote3
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.73
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote4
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.74
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume replicate1
  type cluster/replicate
   option lookup-unhashed off    # off will reduce cpu usage, and network
   option local-volume-name 'hostname'
  subvolumes remote1 remote2
end-volume

volume replicate2
  type cluster/replicate
   option lookup-unhashed off    # off will reduce cpu usage, and network
   option local-volume-name 'hostname'
  subvolumes remote3 remote4
end-volume

volume distribute
  type cluster/distribute
  subvolumes replicate1 replicate2
end-volume

volume iocache
  type performance/io-cache
   option cache-size 8192MB        # default is 32MB
   subvolumes distribute
end-volume

volume writeback
  type performance/write-behind
  option cache-size 1024MB
  option window-size 1MB
  subvolumes iocache
end-volume

### Add io-threads for parallel requisitions
volume iothreads
  type performance/io-threads
  option thread-count 64 # default is 16
  subvolumes writeback
end-volume

volume ra
  type performance/read-ahead
  option page-size 2MB
  option page-count 16
  option force-atime-update no
  subvolumes iothreads
end-volume

32
2017-12-14 13:59


Ursprung


Bitte geben Sie die Ausgabe von cat /proc/self/mounts und (vielleicht ziemlich lang) cat /proc/self/mountinfo. - Matthew Ife
@MIfe Ich habe die Frage aktualisiert, beide Ausgaben sind angehängt. - Wolfgang Stengel
Mein Gefühl hier ist es wahrscheinlich mit NFS Dentry Caching zu tun. Aus Interesse können Sie laufen cat /etc/nfsmount.conf. Haben Sie auch Verzeichnisse, die viele Dateien in ihrem unmittelbaren Verzeichnis enthalten? - Matthew Ife
Nun, da vfs_cache_pressure> 100 ist, sollte der Kernel lieber dentrie cache Speicher zurückfordern. Dies kann leicht ein Bug sein, 2.6.32 ist ziemlich alter Kernel, sogar mit RedHat Backport Patches. BTW, was ist genaue Kernel-Version? - poige
(Ihr Systemadministrator klingt furchtbar. Es gibt uns einen schlechten Namen) - ewwhite


Antworten:


Habe ich recht, wenn ich daran denke, dass der Slab-Speicher immer physikalischer RAM ist und die Zahl bereits vom MemFree-Wert abgezogen wird?

Ja.

Ist eine so hohe Anzahl an Dentry-Einträgen normal? Die PHP-Anwendung hat Zugriff auf ca. 1,5 M-Dateien, die meisten davon sind jedoch Archive und werden überhaupt nicht für den normalen Web-Verkehr genutzt.

Ja, wenn das System nicht unter Speicherdruck steht. Es muss den Speicher für etwas verwenden, und es ist möglich, dass dies in Ihrem speziellen Nutzungsmuster der beste Weg ist, diesen Speicher zu verwenden.

Was könnte eine Erklärung für die Tatsache sein, dass die Anzahl der zwischengespeicherten Inodes viel niedriger ist als die Anzahl der zwischengespeicherten Dentries, sollten sie nicht irgendwie zusammenhängen?

Viele Verzeichnisoperationen wären die wahrscheinlichste Erklärung.

Wenn das System in Speicherprobleme gerät, sollte der Kernel einige der Dentries nicht automatisch freigeben? Was könnte ein Grund sein, dass das nicht passiert?

Es sollte, und ich kann mir keinen Grund vorstellen, würde es nicht tun. Ich bin nicht überzeugt, dass das tatsächlich falsch gelaufen ist. Ich würde dringend empfehlen, den Kernel zu aktualisieren oder vfs_cache_pressure weiter zu erhöhen.

Gibt es eine Möglichkeit, in den Dentry-Cache zu schauen, um zu sehen, was all dieser Speicher ist (d. H. Welche Pfade werden zwischengespeichert)? Vielleicht deutet dies auf eine Art von Speicherverlust, Symlink-Schleife oder tatsächlich auf etwas hin, was die PHP-Anwendung falsch macht.

Ich glaube nicht, dass es da ist. Ich würde nach irgendwelchen Verzeichnissen mit einer absurd großen Anzahl von Einträgen oder sehr tiefen Verzeichnisstrukturen suchen, die durchsucht oder durchsucht werden.

Der PHP-Anwendungscode sowie alle Asset-Dateien werden über GlusterFS-Netzwerk-Dateisystem gemounted, könnte das etwas damit zu tun haben?

Definitiv könnte es ein Dateisystemproblem sein. Ein Dateisystem-Bug, der zum Beispiel dazu führt, dass Dentries nicht freigegeben werden, ist eine Möglichkeit.


12
2017-12-15 01:31



Danke, dass du meine Fragen individuell beantwortet hast. Der Cachedruck wurde schließlich weiter erhöht und der Anstieg des Cache-Speichers gestoppt. - Wolfgang Stengel
Ich konnte das verantwortliche Programm noch nicht aufspüren. Wenn ich mehr herausfinde, melde ich mich für alle anderen, die dieses Problem haben. - Wolfgang Stengel
Vielen Dank! Ein großes Verzeichnis (0.25 Mil Files) war in meinem Fall die Ursache des Problems, jedes Mal wenn etwas damit interagierte, würden 2GB RAM in den Cache verschwinden. - Some Linux Nerd


Bestätigte Lösung

Für jeden, der auf dasselbe Problem stoßen könnte. Die Leute im Rechenzentrum haben es heute herausgefunden. Schuld daran war eine mit Libcurl gebündelte NSS-Bibliothek (Network Security Services). Ein Upgrade auf die neueste Version löste das Problem.

Ein Fehlerbericht, der die Details beschreibt, ist hier:

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1044666

Um festzustellen, ob ein Pfad lokal oder auf einem Netzlaufwerk ist, suchte NSS offenbar nach einer nicht existierenden Datei und maß die Zeit, die das Dateisystem für die Rückmeldung benötigte! Wenn Sie eine ausreichend große Anzahl an Curl-Anfragen und genügend Speicher haben, werden diese Anfragen alle zwischengespeichert und gestapelt.


19
2018-01-24 18:59





Ich bin genau auf dieses Problem gestoßen, und während Wolfgang in der Sache recht hat, fehlt ein wichtiges Detail.

  • Dieses Problem betrifft SSL-Anforderungen, die mit curl oder libcurl oder einer anderen Software, die mozilla NSS für sichere Verbindungen verwendet, ausgeführt werden. Nicht sichere Anforderungen lösen das Problem nicht aus.

  • Das Problem erfordert keine gleichzeitigen Aufrollungsanforderungen. Die Ansammlung von Dentry wird auftreten, solange Curl-Aufrufe häufig genug sind, um die Bemühungen des Betriebssystems, RAM zurückzugewinnen, zu übertreffen.

  • Die neuere Version von NSS, 3.16.0, enthält eine Lösung dafür. Sie erhalten die Fehlerbehebung jedoch nicht kostenlos, indem Sie NSS aktualisieren, und Sie müssen nicht alle NSS aktualisieren. Sie müssen nur nss-softokn (das eine erforderliche Abhängigkeit von nss-utils hat) upgraden. Um den Vorteil zu erhalten, müssen Sie die Umgebungsvariable NSS_SDB_USE_CACHE für den Prozess festlegen, der libcurl verwendet. Das Vorhandensein dieser Umgebungsvariablen ermöglicht es, die kostspieligen nicht vorhandenen Dateiprüfungen zu überspringen.

FWIW, ich schrieb ein Blog-Eintrag mit ein wenig mehr Hintergrund / Details, falls jemand es braucht.


14
2018-06-02 19:30



Danke für einen netten Blogbeitrag, aber ich möchte erwähnen, dass nss-softokn noch nicht auf Version 3.16 auf CentOS / RHEL aktualisiert wurde. Es wird wahrscheinlich in Version 6.6 behoben werden. - Strahinja Kustudic
Danke für die Nachricht. Vielleicht ist Amazon vor diesem (vielleicht sogar auf unsere Bitte?) Für ihre gemanagten Repos ausgestiegen. Bei älteren Versionen (3.14-3.15) erzielen Sie immer noch den halben Vorteil, wenn Sie die entsprechenden Umgebungsvariablen festlegen. Wenn Sie das Know-how haben, können Sie v3.16 direkt erstellen. Andernfalls ist es möglicherweise am besten, den Cachedruck zu erhöhen und den entsprechenden CPU-Treffer zu erzielen, um eine zuverlässige Leistung zu erzielen. - J. Paulding
Dies wird in Centos 6.6 mit nss-softokn-3.14.3-17 behoben - Strahinja Kustudic
Nur um klar zu sein für Leute, die eine schnelle Lösung suchen: Sie müssen beide aktualisieren nss-softoken RPM UND setze die NSS_SDB_USE_CACHE=YES env var, um curl-https-Aufrufe zu haben, stoppe deinen Dentry-Cache. - Steve Kehlet


Sehen https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/broken-out/vfs-shrinkage-tuning.patch

Es gibt Zahlen, die anzeigen, dass Sie eine merkliche Speichererinnerung erwarten können, wenn vfs_cache_pressure auf eine höhere Stufe als 100 gesetzt wird. 125 kann also in Ihrem Fall zu niedrig sein, damit dies geschieht.


3
2017-12-14 16:34



Von allem, was ich gelesen habe, steigend vfs_cache_pressure über 100 macht nur Sinn, wenn Sie nicht genügend Arbeitsspeicher für Ihre Arbeitslast haben. In diesem Fall wird ein Wert von weit über 100 (z. B. 10000) etwas RAM freigeben. Das wird jedoch insgesamt zu schlechteren IO führen. - Mikko Rantalainen


Nicht wirklich eine Erklärung zu Ihrer Antwort, aber als Benutzer dieses Systems haben Sie diese Informationen zur Verfügung gestellt:

cat /proc/meminfo
MemTotal:       132145324 kB
...
SReclaimable:   44561644 kB
SUnreclaim:      1678736 kB

Ist genug, um mir zu sagen, dass das ist nicht dein Problem und es liegt in der Verantwortung des Systemadministrators, eine angemessene Erklärung zu liefern.

Ich möchte hier nicht unhöflich klingen, aber;

  • Ihnen fehlen spezifische Informationen über die Rolle dieses Hosts.
  • Wie der Host Ressourcen priorisieren soll, gehört nicht zu Ihren Möglichkeiten.
  • Sie sind nicht vertraut oder waren an der Entwicklung und Bereitstellung des Speichers auf diesem Host beteiligt.
  • Sie können bestimmte Systemausgaben nicht anbieten, da Sie nicht root sind.

Es ist dein Systemadministratoren Verantwortung um die Anomalie der Brammenzuteilung zu rechtfertigen oder zu lösen. Entweder haben Sie uns kein vollständiges Bild von der ganzen Sage gegeben, die Sie dazu geführt hat (an der ich ehrlich gesagt nicht interessiert bin) oder Ihr Systemadministrator verhält sich unverantwortlich und / oder inkompetent in der Art, wie er dieses Problem behandelt.

Zögern Sie nicht, ihm zu sagen, dass ein zufälliger Fremder im Internet denkt, dass er seine Verantwortung nicht ernst nimmt.


1
2017-12-14 17:22