Tomasz Serwański

Tomasz Serwański Microsoft Dynamics
CRM - konsultant
biznesowy

Temat: redhat / oracle / hugepages

bardzij z pogranicza os/dba niz czyste dba, ale a nuz ktos pomoze..

mam serwer redhata z oraclem, na nim uzywam hugepages; z przyczyn roznych zalezy mi na informacji o zajetosci/uzyciu hugepages, ALE! nie chodzi mi o ilosc; wiem co znalezc w /proc, i nie chodzi mi o ilosc uzytych/wolnych stron, ale o informacje co je zajmuje; szukam sposobu ktory pomoze mi wskazac ze ta strona jest zajeta przez ten proces, kolejna przez inny proces i tak dalej - ktos moze sie zderzyl z takim problemem?

Temat: redhat / oracle / hugepages

ipcs twoim przyjacielem jest :)

Ja zazwyczaj używam ipcs -a. ipcs wyciąga informacje z /proc/sysvipc/shm ale bardziej mi się podoba output z ipcs.

Jak już masz shmid z ipcs to robisz tak:

lsof | egrep "shmid|COMMAND"

np dla shmid 3833860:

lsof | egrep "3833860|COMMAND"

To chyba to o co ci chodzi.Tomasz Wiśniewski edytował(a) ten post dnia 08.02.12 o godzinie 21:57
Tomasz Serwański

Tomasz Serwański Microsoft Dynamics
CRM - konsultant
biznesowy

Temat: redhat / oracle / hugepages

Tomasz Wiśniewski:
To chyba to o co ci chodzi.
ha, gdyby tylko ipcs mial mozliwosc ograniczenia sie do huge pages - wtedy tak, to byloby rozwiazanie :) niestety pokazuje calosc pamieci w kupie, bez znaczenia co jest zaalokowane z zwyklych, a co w huge pages, stad.. nadal szukam :)

Temat: redhat / oracle / hugepages

Czyli tak naprawdę chodzi Ci o sprawdzanie który segment shm (shmid) znajduje się w huge pages. Niestety chyba nie prostej metody na to w linuxie.
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: redhat / oracle / hugepages

Nie da się w prosty sposób :)

Aplikacja tworząca segment pamięci wspóldzielonej, który ma bazować na huge pages odpowiednio to zaznacza w wywołaniu systemowym shmget, np.


shgmet(klucz, rozmiar, IPC_CREAT|IPC_EXCL|SHM_HUGETLB|S_IRWX|S_IRGRP);

IPC_CREAT - tworzy nowy segment
IPC_EXCL - zapewnia, że zostanie zgłoszony błąd jeśli segment już istnieje
SHM_HUGETLB - utwórz segment korzystąjc z huge pages
S_IRWXU - właściciel ma prawo do zapisu/odczytu/wykonania
S_IRGRP - grupa ma prawo do odczytu


W Linuksie (przynajmniej w kernelu 2.6.31.13) nie jest zachowywana informacja o wszystkich flagach, które zostały przekazane do wywołania systemowego shmget, tzn. przechowywane są wartości: (FLAGS & 777), tj. informacje o uprawnieniach właściciela/grupy/innych użytkowników.

Jednak przy tworzeniu segmentu pamięci współdzielonej w filesystemie pamięci wirtualnej tworzony jest wpis tj. inode# o identyfikatorze odpowiadającym identyfikatorowi segmentu.

Dla "zwykłych" stron wpis tworzony jest w shmfs, zaś dla stron huge pages w hugetlbfs, efekt jest taki, że tę informację można znaleźć w /proc/<pid>/maps, o ile ma się te file systemy podmontowane.

Dla zwykłych stron nazwa skojarzona z inode# to SYSV<klucz>, zaś dla huge pages to po prostu kolejny numer z sekwencji kernelowej.

Nie mam niestety pod ręką Linuksa z obsługą huge pages by skonfrontować teorię z rzeczywistością.
Tomasz Serwański

Tomasz Serwański Microsoft Dynamics
CRM - konsultant
biznesowy

Temat: redhat / oracle / hugepages

Paweł Grzegorz Kwiatkowski:
idea bardzo obiecujaca, niestety wyglada na to ze w zadnym wpisie w /proc/[pid] nie ma nic o shmfs lub hugetlbfs, stad.. chyba tez nie tedy droga :) dalej pomysly wskazane

Temat: redhat / oracle / hugepages

No Pawle dobry mykens tyle że nie ma tam takich informacji sprawdziłem na 2.6.18, 2.6.32-uek, 2.6.36.

Tomku a powiedz nam może po co Ci to potrzebne?:) Bo może twój problem da się jakoś inaczej rozwiązać.
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: redhat / oracle / hugepages

Po dodatkowym zbadaniu sprawy, wygląda, że są to anonimowe inody i stąd brak wpisów na tych specjalnych file systemach :)

Per proces można sprawdzić czy segment SHM jest zamapowany do przestrzeni adresowej (za pomocą wspomnianego lsof bądź /proc/<pid>/maps, dla segmentów pamięci współdzielonej semid=inode).

Skoro inode jest podany dla segmentu, to kwestia w którym filesystemie (SHM/HUGETTLB) został utworzony. Wygląda, że tu może być pomocne pole DEVICE: major,minor

Podejrzewam, że dla tych filesystemów
MAJOR = 0
MINOR = wewnętrzny identyfikator kernela, pozwalający odróżnić fizyczne byty

Ale który MINOR odpowiada któremu fs, można by określić eksperymentalnie, np. przez proste utworzenie segmentu korzystającego z HUGETLB + segmentu nie korzystającego z huge TLB + podłączenie zamapowanie tychże segmentów na przestrzeń adresową proces + losf PID :)

Jak znajdę czas na zbudowanie kernela ze wsparciem dla Huge Pages, to potestuję dalej, ale póki co szkic poniżej.
MINOR pewnie będzie się różnić per maszyna / restart maszyny (kolejność tworzenia struktur kernelowych).


#include <stdio.h>
#include <sys/shm.h>
#include <sys/ipc.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <errno.h>

int main() {
key_t key = 0x666777;
int shmid = -1, shmid2 = -1, rc = -1;
void *shm_addr = NULL, *shm_addr2 = NULL;
struct shmid_ds buf, buf2;
char *c;

shmid = shmget ( key, 8192*32,IPC_CREAT|IPC_EXCL|S_IRWXU|S_IRGRP);
if (shmid == -1 ) {
printf("Blad przy tworzeniu segmentu. Errno=%d\n",errno);
} else {
printf("SHMID =%d\n",shmid);
shm_addr = shmat(shmid, NULL, SHM_RDONLY );
if (shm_addr == (void *) -1 ) { printf("Blad dolaczania segmentu do przestrzeni adresowej procesu. Errno=%d\n",errno); } else { printf("SHMID %d attached at %X\n",shmid,shm_addr); }
}


shmid2 = shmget ( key+1, 8192*32,SHM_HUGETLB|IPC_CREAT|IPC_EXCL|S_IRWXU|S_IRGRP);
if (shmid2 == -1 ) {
printf("Blad przy tworzeniu segmentu HTLB. Errno=%d\n",errno);
} else {
printf("SHMID HTLB =%d\n",shmid2);
shm_addr2 = shmat(shmid2, NULL, SHM_RDONLY );
if (shm_addr2 == (void *) -1 ) { printf("Blad dolaczania segmentu do przestrzeni adresowej procesu. Errno=%d\n",errno); } else { printf("SHMID %d attached at %X\n",shmid2,shm_addr2); }
}

printf("Press ENTER to continue...\n");
scanf("%c",&c);

if (shm_addr != NULL ) {
if ( shmdt(shm_addr) == -1 )
{
printf("Error detaching shm segment. Errno=%d\n",errno);
}
else
{
printf("SHM segment detached.\n");
}
}

if (shm_addr2 != NULL ) {
if ( shmdt(shm_addr2) == -1 )
{
printf("Error detaching shm HTLB segment. Errno=%d\n",errno);
}
else
{
printf("SHM HTLB segment detached.\n");
}
}

printf("Usuwanie segmentow SHM\n");
shmctl(shmid2,IPC_RMID,&buf2);
shmctl(shmid,IPC_RMID,&buf);


return 0;
}


-- edit
Przy shmid2 wkradł sie brak flagi SHM_HUGETLB.Paweł Grzegorz Kwiatkowski edytował(a) ten post dnia 22.02.12 o godzinie 13:18
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: redhat / oracle / hugepages

No i po testach z Huge Pages :)


debian:/home/yarel# ./test
SHMID =1048593
SHMID 1048593 attached at B7D8F000
SHMID HTLB =1081362
SHMID 1081362 attached at B7800000
Press ENTER to continue...

...

debian:~# ps -ef | grep test
root 3494 3082 0 14:16 pts/1 00:00:00 ./test
root 3505 3496 0 14:17 pts/2 00:00:00 grep test


debian:~# cat /proc/3494/maps
08048000-08049000 r-xp 00000000 03:01 188707 /home/yarel/test
08049000-0804a000 rw-p 00000000 03:01 188707 /home/yarel/test
b7800000-b7c00000 r--s 00000000 00:0b 1081362 /SYSV00666778 (deleted)
b7d8f000-b7dcf000 r--s 00000000 00:08 1048593 /SYSV00666777 (deleted)
b7dcf000-b7dd0000 rw-p b7dcf000 00:00 0
b7dd0000-b7f25000 r-xp 00000000 03:01 833389 /lib/i686/cmov/libc-2.7.so
b7f25000-b7f26000 r--p 00155000 03:01 833389 /lib/i686/cmov/libc-2.7.so
b7f26000-b7f28000 rw-p 00156000 03:01 833389 /lib/i686/cmov/libc-2.7.so
b7f28000-b7f2b000 rw-p b7f28000 00:00 0
b7f35000-b7f39000 rw-p b7f35000 00:00 0
b7f39000-b7f3a000 r-xp b7f39000 00:00 0 [vdso]
b7f3a000-b7f54000 r-xp 00000000 03:01 824174 /lib/ld-2.7.so
b7f54000-b7f56000 rw-p 0001a000 03:01 824174 /lib/ld-2.7.so
bff40000-bff55000 rw-p bffeb000 00:00 0 [stack]

debian:~# lsof -p 3494 | more
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
test 3494 root cwd DIR 3,1 4096 188474 /home/yarel
test 3494 root rtd DIR 3,1 4096 2 /
test 3494 root txt REG 3,1 8013 188707 /home/yarel/test
test 3494 root DEL REG 0,11 1081362 /SYSV00666778
test 3494 root DEL REG 0,8 1048593 /SYSV00666777
test 3494 root mem REG 3,1 1413540 833389 /lib/i686/cmov/libc-2.7.so
test 3494 root mem REG 3,1 113248 824174 /lib/ld-2.7.so
test 3494 root 0u CHR 136,1 3 /dev/pts/1
test 3494 root 1u CHR 136,1 3 /dev/pts/1
test 3494 root 2u CHR 136,1 3 /dev/pts/1




Segmenty zalokowane z HUGETLB można odróżnić od zwykłuch stron po MINOR device number z /proc/<pid>/maps.

Minus tej metody jest taki, że jeśli jakiś proces nie mapuje segmentu SHM, to się nie da :P No chyba, że napisać własny kawałek kodu, który na chwilkę podłączy segment o danym shmid, podejrzeć minor device i gotowe.

Temat: redhat / oracle / hugepages

Faktycznie działa! W sumie moja pierwsza odpowiedź była dobra bo widać to co trzeba ale nie napisałam o minor,major device co było tutaj kluczowe dla zdefiniowania czy dany segment korzysta z huge pages.
Tomasz Serwański

Tomasz Serwański Microsoft Dynamics
CRM - konsultant
biznesowy

Temat: redhat / oracle / hugepages

dopiero zajrzalem.. dzieki sugestiom PAwla zajrzalem do proc, ale do innego pliku - wyglada na to ze dla:

do cat /proc/$i/numa_maps

gdzie $i to PID output pokazuje:

[root@xx~]# cat /proc/32766/numa_maps | grep huge
60000000 default file=/647\040(deleted) huge dirty=34 N0=1 N1=1 N3=32
68000000 default file=/648\040(deleted) huge dirty=6080 N0=1466 N1=1465 N2=1467 N3=1546 N4=33 N5=30 N6=29 N7=44
360000000 interleave=0-7 file=/649\040(deleted) huge dirty=1 N0=1
[root@xx~]#

pomijam ze pozostaja do zinterpretowania wielkosci (tu: 34 i 6080), ale wyglada na to ze da sie w ten sposob powiazac proces ze strona hugepage (w zasadzie z informacja czy proces uzywa czy nie) - takze dzieki :)Tomasz Serwański edytował(a) ten post dnia 28.02.12 o godzinie 17:03
Tomasz Serwański

Tomasz Serwański Microsoft Dynamics
CRM - konsultant
biznesowy

Temat: redhat / oracle / hugepages

a pytanie kolejne, bedace w zasadzie zroblem do powyzszego:

- mam serwer z oraclem
- na nim zdefiniowane hugepages, zalozmy ze mam 1024 hugepages po 2mb kazda
- bazy uzywaja hugepages; zalozmy ze mam 2 bazy uzywajace po 500 hugepages kazda
- problem jaki mam to to, ze przy skladaniu baz hugepages powinny byc zwalniane - a tak sie nie zawsze dzieje

w mniej wiecej 20% przypadkow czesc hugepages pozostaje zajeta przy czym nie wiadomo przez co (sposob jak powyzej nie pokazuje zadnych procesow ktore uzywaja hugepages); sytuacja wyglada tak ze:
1) restart, wstaja obie bazy uzywajac hugepages
2) restartuje baze - w 80% przypadkow sie podniesie bez problemu
3) pozostale 20% przypadkow to problem - baza nie wstaje bo nie ma wystarczajacej ilosci wolnych hugepages; sposob jak wyzej nie pokazuje zadnego procesu uzywajacego hugepages, ale cat /proc/meminfo | grep -i hugepage pokazuje ze 512 hugepages jest uzytych

ktos sie z czyms podobnym spotkal? moze rozwiazal? podobny problem byl raportowany tutaj:
https://bugzilla.redhat.com/show_bug.cgi?id=428612

niestey, mimo ze niby rozwiazany to mam dokladnie to samo (inny kernel?); otworzylem case do rh, dostalem informacje ze przypadek z linku to faktycznie podobny, wiec teraz RH poszuka czy cos podobnego raportowano dla nowych kerneli i zadnej odpowiedzi do tej pory.. :( help.

Temat: redhat / oracle / hugepages

No ja równiez się z tym spotkałem i nie tylko na Linuxie ale również na AIX. Nie wiem czy to nie jest raczej bug oracle który nie zwalnia hugepages poprawnie.

konto usunięte

Temat: redhat / oracle / hugepages

Tomasz Serwański:
a pytanie kolejne, bedace w zasadzie zroblem do powyzszego:

- mam serwer z oraclem
- na nim zdefiniowane hugepages, zalozmy ze mam 1024 hugepages po 2mb kazda
- bazy uzywaja hugepages; zalozmy ze mam 2 bazy uzywajace po 500 hugepages kazda
- problem jaki mam to to, ze przy skladaniu baz hugepages powinny byc zwalniane - a tak sie nie zawsze dzieje

No nie są ... zawsze są odseparowane/zajęte ... dlatego ja osobiście przestałem tego używać i rekomenduję wszystkim tego nie używać (aale rym). A jakie problemy, gdy się pomylisz i łączny rozmiar hugepages > rozmiar pamięci RAM :) Serwer praktycznie nie wstaje i trzeba go reanimować w single user a czasami edytując grub.conf ...
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: redhat / oracle / hugepages

Tomasz Serwański:
dopiero zajrzalem.. dzieki sugestiom PAwla zajrzalem do proc, ale do innego pliku - wyglada na to ze dla:

do cat /proc/$i/numa_maps

gdzie $i to PID output pokazuje:

[root@xx~]# cat /proc/32766/numa_maps | grep huge
60000000 default file=/647\040(deleted) huge dirty=34 N0=1 N1=1 N3=32
68000000 default file=/648\040(deleted) huge dirty=6080 N0=1466 N1=1465 N2=1467 N3=1546 N4=33 N5=30 N6=29 N7=44
360000000 interleave=0-7 file=/649\040(deleted) huge dirty=1 N0=1
[root@xx~]#

pomijam ze pozostaja do zinterpretowania wielkosci (tu: 34 i 6080), ale wyglada na to ze da sie w ten sposob powiazac proces ze strona hugepage (w zasadzie z informacja czy proces uzywa czy nie) - takze dzieki :)

dirty = ilość strony typu "dirty" :) czyli coś po nich napisało, ale strony te jeszcze nie wylądowały w swapie.

N<x>=<y> - ilość stron z określonej puli (pule lokalne per CPU). Wygląda jakby powyższe było wynikiem z maszyny co najmniej 8-corowej. To tak na marginesie.

W kontekście problemów o których piszesz, tj. po położeniu bazy, huge pages nie są zwalniane, to widzę 3 opcje:

1) Kernel którego używasz nie posiada patcha o którym mowa w przytoczonej bugzilli - znając wersję kernela, trzeba by pobrać źródła redhatowego kernela i sprawdzić czy nie wystąpiła regresja. Patch wygląda na bardzo prosty, raptem 2 linijki :)

2) PDFLUSH nie jeździ po tych stronach i są nadal dirty, byłoby to dziwne, ale może warte sprawdzenia. Przyjrzałbym się parametrom:
hugepages_treat_as_movable
dirty_background_bytes
dirty_background_ratio

3) ... jakiś inny błąd :P

pozdr,
Paweł

Temat: redhat / oracle / hugepages

Krzysztof P.:
Tomasz Serwański:
a pytanie kolejne, bedace w zasadzie zroblem do powyzszego:

- mam serwer z oraclem
- na nim zdefiniowane hugepages, zalozmy ze mam 1024 hugepages po 2mb kazda
- bazy uzywaja hugepages; zalozmy ze mam 2 bazy uzywajace po 500 hugepages kazda
- problem jaki mam to to, ze przy skladaniu baz hugepages powinny byc zwalniane - a tak sie nie zawsze dzieje

No nie są ... zawsze są odseparowane/zajęte ... dlatego ja osobiście przestałem tego używać i rekomenduję wszystkim tego nie używać (aale rym). A jakie problemy, gdy się pomylisz i łączny rozmiar hugepages > rozmiar pamięci RAM :) Serwer praktycznie nie wstaje i trzeba go reanimować w single user a czasami edytując grub.conf ...


Jak masz 1024 HugePages to faktycznie moze nie warto ich uzywac - chodz
z drugiej strony mi serwery zdychaja wlasnie jak ich nie zdefiniuje.
Przy buffer_cache okolo 50 - 60 GB narzut na obsluge RAM-u bez HugePages zaczyna byc widoczny.

Ale fakt wredny ten bug z niezwalnianiem - szczegolnie jak wlasnie robisz fail over i nowy primary po restarcie mowi ze ma Cie ... znaczy ze nie ma pamieci :-P

pozdrawiam,
Marcin

Następna dyskusja:

Odinstalowanie Olap, Datami...




Wyślij zaproszenie do