[PL] Bug miesiąca – Lock pages in memory w Standard Edition
Jeśli zdarzyło Ci się kiedykolwiek, że w logach SQL Servera (najpewniej wersja 2005 lub 2008 Standard Edition na platformie 64-bit) pojawił się niepokojący wpis mniej więcej tej treści:
A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 24484, committed (KB): 48036, memory utilization: 50%
to znaczy, że ta notka jest dla Ciebie :-)
Prawdopodobnie powyższy komunikat oznacza, że właśnie masz całkiem poważny problem wydajnościowy na swoim serwerze. Strony baz danych, które powinny być w jak największej ilości trzymane w pamięci, wylatują z tej pamięci w szybkim tempie i muszą być ponownie czytane z dysku przy wykonywaniu zapytań przez użytkowników. Ponoć problem leży w sterownikach i w błędach w systemie Windows (zwłaszcza Windows Server 2003). System ma problem w sytuacji, gdy jeden proces (SQL Server) zajmuje znaczną większość pamięci, a inny proces o tę pamięć walczy. Wówczas może nastąpić stronicowanie pamięci i zaczyna się niszczycielski proces wyrzucania stron z danymi z buffer cache’a. SQL Server może się bronić przed takim efektem. Wystarczy ustawić dla konta Windows, w kontekście którego działa usługa SQL Server, uprawnienie Lock Pages in Memory w polisach systemu Windows. Ustawienie tego uprawnienia dla konta SQL Servera powoduje, że SQL Server utrzyma strony danych w pamięci nawet, gdy system operacyjny będzie szukał zasobów dla innych procesów. Wszystko fajnie, ale ustawienie wspomnianego uprawnienia przynosi rezultat tylko, gdy mamy do czynienia z SQL Server Enterprise Edition… Edycja Standard ignoruje to ustawienie. Rodzi się pytanie – czy jest więc sens pakować więcej niż 4GB RAM w serwery z edycją Standard? Bo przecież wystarczy, że przy dobrze obciążonym serwerze wykorzystującym w pełni buffer cache uruchomimy dodatkowo jakiś proces, który będzie walczył o zasoby i możemy dostać małą katastrofę wydajnościową. Sam MS pisze na blogach, że to się daje ugasić za pomocą hotfix’ów i Service Packa do SQL Servera (http://blogs.msdn.com/psssql/archive/2007/05/31/the-sql-server-working-set-message.aspx), ale wygląda na to, że jednak to nie do końca prawda, bo wciąż ludzie informują, że mieli podobne zjawisko na swoich serwerach.
Naturalnym rozwiązaniem wydaje się po prostu dodanie wsparcia dla Lock Pages in Memory w edycji Standard. Jednak MS się miga. Na nic tłumaczenia, że brak owego wsparcia powoduje praktycznie nierozwiązywalne problemy wydajnościowe i że takie traktowanie klientów posiadających edycję Standard nie jest właściwe.
Ostatnio ciężką walkę o naprawienie buga (bo to wg mnie i wg wielu profesjonalistów pracujących z SQL Server oczywisty bug) podjął Maciek Pilecki. Jednym ze środków walki jest wątek na connect.microsoft.com:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=422322
Podobny wątek istniał już kiedyś, ale został zamknięty. Warto więc tym razem dać naprawdę porządny, masowy feedback MS, żeby nie mogli po prostu przejść obok problemu obojętnie. A zatem, kupą mości Panie i Panowie :-) Wchodźcie na wątek i głosujcie, szczególnie jeśli macie na serwerze SQL Server 2005/2008 Standard Edition 64-bit. Bo lada dzień problem może dotknąć i Was.
A ci z Was, którzy doświadczyli problemu, niech spróbują zrobić case study (można je wysłać chociażby do mnie – pawel[dot]potasinski[at]sqlpass[dot]org). Nie ma to jak namacalne dowody. Wysłalibyśmy je do MS, żeby ludzie z Redmond na własne oczy przekonali się, jaką krzywdę robią klientom, którym wydawało się, że nie potrzebują edycji Enterprise, bo nikt im wcześniej nie powiedział, że taki bug istnieje na edycji Standard.
PS. Nie tylko ja piszę o tym problemie. Zablogował o nim chociażby Simon Sabin (SQL Server MVP).