Na moim serwerze pojawił się błąd „out of memory”. Zdarza się, ale akurat na tym serwerze nie powinno… Maszyna ma 16 GB RAM i dwie instancje SQL. Jedna z nich rzeczywiście zasobów potrzebuje nieco więcej, ale druga to właściwie utrzymuje kilka małych bazek. Badanie problemu, jak to zwykle zacząłem od sprawdzenia czy rzeczywiście brakuje pamięci. Wyglada na to, że cała jest wykorzystana.
A jakie procesy ją zabrały? Może to wcale nie SQL? Posortowałem procesy wg. ilości pamięci i okazało się, że owszem – SQL zabiera najwięcej pamięci, ale daleko mu do 16GB, które znajdują się w systemie.
To gdzie jest moje 10GB RAM? Kto zabrał moją pamięć i w jaki sposób to przedemną ukrywa? W takim przypadku bardzo się przydaje narzędzie z pakietu sysinternals: RAMMapper:
Narzędzie pozwoliło mi ustalić, że 10GB przypadło dla Driver Locked. Niedobrze – to może oznaczać wyciek pamięci. Jakiś sterownik ma bardzo duży apetyt na pamięć. Tylko jaki to sterownik? Poszperałem trochę w sieci i okazało się, że jednym z podejrzanych steroników mógby być VMWare – a ta maszyna rzeczywiście jest wirtualna. Na forum https://communities.vmware.com/message/1714223 znalazłem dość ciekawy trop, który przytaczam tu w całości:
After doing reading this article I reviewed the resource allocation settings for the VM and found the memory limit was set to 1GB (whereas I’d assigned 4GBs to the client). Once I reset the limit the memory usage dropped significantly to an „expected” amount of around 22%. So basic configuration of the VM was the issue here for me and might be for others if it is not an over-allocation of the hosts (our hosts have sufficient memory).
Zostało tylko zapytać o te ustawienia administratora VMWare, który potwierdził przyczynę. Bingo!
