PowerFlex: Niepowodzenie przełączania MDM z powodu błędów alokacji pamięci — mos_MemMalloc

Dane wyjściowe zdarzeń z odbierającego pliku MDM /opt/emc/scaleio/mdm/bin/showevents.py będą zawierały wiele wpisów dotyczących próby przejęcia obowiązków głównego MDM, wszystkie w krótkim odstępie czasu:  

 2017-10-04 12:08:33.915 MDM_CLUSTER_BECOMING_MASTER WARNING This MDM, ID 394760fd6714xxxx, took control of 
the cluster and is now the Master MDM. 2017-10-04 12:08:33.915 MDM_BECOMING_MASTER WARNING This MDM is
 switching to Master mode. MDM will start running. .. 2017-10-04 12:08:34.309 MDM_CLUSTER_BECOMING_MASTER 
WARNING This MDM, ID 394760fd6714xxxx, took control of the cluster and is now the Master MDM. 
2017-10-04 12:08:34.309 MDM_BECOMING_MASTER WARNING This MDM is switching to Master mode. MDM will start 
running.

Plik exp.0 z odbierającego MDM zawiera następujące wpisy: 

 04/10 12:08:34.079823 Panic in file /data/build/workspace/ScaleIO-SLES12-2/src/mos/usr/mos_utils.c, line 73, 
function mos_MemMalloc, PID 9978.Panic Expression bCanFail . /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(
mosDbg_PanicPrepare+0x115) [0x6a86f5] /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(mos_MemMalloc+0x81) 
[0x6ac0d1] /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(multiHeadMgr_GetUpdateMultiHeadsMsg+0x66) [0x57123c]
 /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(tgtMgr_ConfigureTgt+0x9c1) [0x4d579e] 
/opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(tgtMgr_HandleWorkReq+0x41b) [0x4d6206] 
/opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211() [0x6c57d8] 
/opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(mosUmt_StartFunc+0xea) [0x6c51af]
 /opt/emc/scaleio/mdm/bin/mdm-2.0.13000.211(mosUmt_SignalHandler+0x51) [0x6c65d1]
 /lib64/libpthread.so.0(+0x10b00) [0x7f844e8a6b00] /lib64/libc.so.6(sleep+0xd4) [0x7f844d8911a4]

Plik /var/log/messages pokazuje wiele ponownych uruchomień usługi MDM, tak jak robi to events.txt: 

 systemd[1]: mdm.service: Main process exited, code=exited, status=255/n/a systemd[1]: mdm.service: 
Unit entered failed state. systemd[1]: mdm.service: Failed with result 'exit-code'. systemd[1]: mdm.service:
 Service has no hold-off time, scheduling restart. systemd[1]: Stopped scaleio mdm. systemd[1]: mdm.service: 
Start request repeated too quickly. systemd[1]: Failed to start scaleio mdm. systemd[1]: mdm.service: Unit 
entered failed state. systemd[1]: mdm.service: Failed with result 'start-limit'.

To nie jest problem ScaleIO. ScaleIO działa zgodnie z projektem.

Aby sprawdzić i/lub zmodyfikować ustawienia vm.overcommit, wykonaj następujące kroki:

1. Zaloguj się do SDS przy użyciu SSH jako użytkownik root

2. Uruchom 

cat /etc/sysctl.conf | grep "vm.overcommit"
Ex.
[root@sds-node logs]# cat /etc/sysctl.conf | grep "vm.overcommit"
vm.overcommit_memory = 2
vm.overcommit_ratio = 50

3, Uruchom następujące polecenia.

sed -i 's/vm\.overcommit_memory = .*/vm\.overcommit_memory = 2/g' /etc/sysctl.conf
sed -i 's/vm\.overcommit_ratio = .*/vm\.overcommit_ratio = 100/g' /etc/sysctl.conf
sysctl -p

Weryfikacja

[root@sds-node logs]# cat /etc/sysctl.conf | grep "vm.overcommit"
vm.overcommit_memory = 2
vm.overcommit_ratio = 100

Powtórz te czynności dla wszystkich dysków SDS, których dotyczy problem, w środowisku, aby upewnić się, że ustawiono na nich zalecane ustawienia najlepszych rozwiązań. Aby wykonać tę operację, nie trzeba przełączać SDS w tryb konserwacji. 

Aby dowiedzieć się więcej o tych ustawieniach, zapoznaj się z dokumentacją jądra systemu Linux dotyczącą rozliczania nadmiernego zatwierdzenia

Sprawdź parametry jądra sysctl pod kątem nadmiernego zaangażowania pamięci:

# sysctl -a |grep commit
vm.overcommit_memory = 2 (default is 0)
vm.overcommit_ratio = 50 (default is 50)

W takim przypadku ustawienie "vm.overcommit_memory" na 2 oznacza, że nie należy nadmiernie angażować pamięci. Alokacja pamięci przekraczająca limit nadmiernego zatwierdzenia kończy się niepowodzeniem. Łączna wartość zatwierdzonej przestrzeni adresowej systemu nie może przekraczać swap + konfigurowalna ilość (domyślnie 50%) fizycznej pamięci RAM. Gdy to ustawienie jest równe 0, odrzuca oczywiste żądania nadmiernego zatwierdzenia, ale procesy główne mogą alokować powyżej limitu nadmiernego zatwierdzenia. 

Aby sprawdzić bieżący limit nadmiernej commitacji i zatwierdzoną kwotę, zobacz odpowiednio CommitLimit i Committed_AS z poziomu następującego polecenia:

#cat /proc/meminfo 
MemTotal: 8174572 kB 
.. 
CommitLimit: 4087284 kB 
Committed_AS: 3879388 kB

Na tym hoście znajduje się 8 GB pamięci RAM, a CommitLimit jest ustawiony na ~4 GB, co stanowi 50% całkowitej przestrzeni adresowej.

Aby rozwiązać ten problem, dodaj/edytuj jedną z następujących rzeczy w pliku /etc/sysctl.conf:

 - Zmień wartość "vm.overcommit_ratio" na 100, aby system operacyjny mógł zatwierdzić całkowitą dostępną przestrzeń adresową i uruchomić się ponownie.