Jestem częścią małej firmy, która jak zwykle obejmuje wiele różnych ról. Najnowszym z nich jest zakup dedykowanego serwera SQL Server dla naszej aplikacji internetowej .NET. Cytowano nas na podwójnej konfiguracji procesora Xeon E5-2620 (sześciordzeniowy) 2,00 GHz (łącznie 12 rdzeni) z 32 GB pamięci RAM. To pozostawiło nam ograniczony budżet na macierz dyskową, która zasadniczo składałaby się z dwóch 2,5-calowych dysków SAS 300 GB (15k RPM) w konfiguracji RAID 1.
Wiem, że konfiguracja dysku nie jest optymalna dla SQL Server i naprawdę chciałbym wypchnąć RAID 10, abyśmy mogli umieścić bazę danych, pliki dziennika i tempdb na własnych dyskach. Czy w celu zapewnienia zgodności z naszym budżetem należy rozważyć zmniejszenie liczby rdzeni procesora? lub czy dostanę lepszy bank za grosze, zachowując rdzenie i używając mniejszej liczby dysków, być może 4 w konfiguracji z podwójnym RAID 1?
Oto kilka dodatkowych statystyk
Baza danych SQL Server jest przechylona w kierunku dużej liczby odczytów do zapisów, prawdopodobnie odpowiednio 80% w porównaniu z 20%. Obecny rozmiar bazy danych wynosi obecnie około
10 GB26 GB, rosnąc w tempie 250 MB miesięcznie.Obecnie działa na SQL Server 2008 R2 Standard na pojedynczym czterordzeniowym pudełku Xeon współdzielonym z serwerem internetowym (12 GB RAM, 2 dyski SAS 10 x 300 GB SAS w RAID 1), chcąc przejść do SQL Server 2012 Standard.
Baza danych obsługuje około 100-150 równoczesnych użytkowników z pewnymi zadaniami planowania w tle. Czytając to, myślę, że 12 rdzeni to poważna przesada!
Wdrożyłem całą aplikację w usłudze chmurowej Azure (2 małe instancje) połączonej z bazą danych SQL Azure. Chociaż wydajność była rozsądna podczas testowania (prawie zerowe obciążenie), straciłem odwagę do użycia w produkcji z powodu nieprzewidywalności, o której tyle czytałem. Może działać lepiej z podejściem skalowalnym w poziomie, ale mając zaledwie 10 GB bazy danych prawdopodobnie prawdopodobnie uda mi się teraz skalować i zaoszczędzić trochę gotówki.
Początkowo przeoczyłem koszty licencyjne i nie zdawałem sobie sprawy, że licencjonowanie SQL Server 2012 opiera się na liczbie rdzeni. Mam subskrypcję BizSpark MSDN z licencją SQL Server 2012 Standard, więc muszę przeczytać, ile rdzeni zużyłoby to po wyjęciu z pudełka.
Odpowiedzi:
Mówiąc z doświadczenia, które jest skromne, ale myślę, że warto się dzielić, głównym wąskim gardłem w bazach danych SQL (tutaj Sybase i serwer SQL) jest przechowywanie.
Ale myślę, że to uczciwe, że ktoś najpierw porównuje swoją konfigurację, zanim podejmie jakiekolwiek błędne założenia. W moim przypadku użycie procesora nigdy nie wzrosło wystarczająco wysoko, aby uzasadnić aktualizację procesora w najbliższym czasie. Zamiast tego zaktualizowałem system z jednego dysku do RAID 1, a następnie do RAID 10 + bump z 8 GB do 16 GB pamięci RAM.
Wszystkie te aktualizacje RAID pomogły skrócić poprzednie czasy oczekiwania 2 do 6 razy. Podejrzewam, że aktualizacja na dyski SSD byłaby jeszcze lepsza. Jeśli się nad tym zastanowić, można to wszystko zredukować do (teoretycznej) przepustowości. Kombinacja [(szybkość RAM + rozmiar RAM + kontroler pamięci) do procesora] ma limit przepustowości, który byłby najważniejszym czynnikiem w operacjach odczytu, kiedy dane powinny być zawsze buforowane, twoja pamięć masowa (RAID) ma limit przepustowości ( wpływa na odczyty w przypadku braku pamięci podręcznej i zapisuje podczas opróżniania lub gdy wielu klientów zapisuje wiele danych łącznie).
Normalizuj wszystkie te limity tak bardzo, jak to możliwe (przybliż je, aby nie zmarnować zasobów) i zwiększaj je jak najwięcej (uaktualnij w razie potrzeby i tylko w razie potrzeby, nie pozwól marnować zasobów, jeśli system wygra ” być w stanie ich użyć, ponieważ przeszkadza w tym inne wąskie gardło). W końcu twoim najgorszym wąskim gardłem będzie najmniej wydajny (z najmniejszą przepustowością) podsystem serwera w twojej konkretnej konfiguracji.
Mogę też dodać, że w trakcie aktualizacji stworzyłem osobne konfiguracje RAID dla plików bazy danych i plików dziennika bazy danych. Powodem było to, że pliki dziennika bazy danych zwykle wymagają intensywnego zapisu. Plik dziennika służy do odzyskiwania bazy danych po awarii i jest zawsze zapisywany natychmiast po zatwierdzeniu transakcji, zanim jakiekolwiek dane zostaną zapisane w pliku bazy danych.
Plik dziennika jest również używany przez niektóre serwery replikacji bazy danych, ale większość replikacji nie jest wykonywana natychmiast, ale często, więc wpływ na wydajność odczytu jest tutaj minimalny. Tak mi się przynajmniej wydaje. Dokonując tego uaktualnienia, przeprowadziłem minimalne testy porównawcze, więc ponownie polecam każdemu najpierw przetestowanie różnych konfiguracji i najpierw ulepszenie pamięci, a następnie pamięci RAM i łącza sieciowego, zanim pomyśli o ulepszeniu procesorów.
Po bardziej rozbudowanych aktualizacjach na więcej niż 5 serwerach wróciłem, aby podzielić się swoim doświadczeniem. Zdecydowanie nadal opowiadam się za pierwszą aktualizacją pamięci, potem pamięci RAM, a następnie procesora. Powodem jest rozbieżność przepustowości w systemie między pamięcią, pamięcią RAM i procesorem, w kolejności od najniższej do najwyższej. Więc zaktualizowałem kilka serwerów z RAID10 i podwójnych RAID1 na SSD.
Sposób, w jaki to zrobiłem ze względu na koszty (mam 20 dodatkowych serwerów do aktualizacji), polega na przeniesieniu plików danych i obiektów obiektów na dysk SSD (tak, tylko jeden dysk SSD w RAID0) i przeniesienie dziennika transakcji plus tempdb na 4xHDD RAID10 konfiguracja. Testowałem również z tempdb na SSD, a także ze świetnymi wynikami (w rzeczywistości bardzo dobre wyniki z czasami ponad 15 razy szybszymi zapytaniami, co dało niektóre raporty zajmujące sekundy zamiast minut), ale później przeniosłem tempdb na dysk RAID10, ponieważ intensywnych problemów związanych z zużyciem zapisu na dysku SSD.
Więc teraz w zasadzie zaobserwowałem 10-15 razy krótszy czas odpowiedzi na jedno z najdłuższych zapytań. SSD doskonale nadaje się do szybkiego odczytu danych do pamięci RAM, ponieważ SQL Server nie przenosi danych do pamięci RAM, dopóki nie zostanie o to poproszony i oczywiście dane muszą najpierw zostać załadowane do pamięci RAM w celu przetworzenia przez procesor (później w pamięci podręcznej L1, L2, L3) , więc dyski SSD znacznie zmniejszają początkowy czas oczekiwania. A dyski SSD pomagają również skrócić czas zamiany ... czyszczenie pamięci RAM i ładowanie nowych danych, szczególnie jeśli baza danych jest większa niż mieści się w pamięci RAM.
Podsumowując, jesteśmy bardzo zadowoleni i działamy tak przez kilka miesięcy w rodzaju powolnego procesu migracji, aby umożliwić działanie serwerów, dzięki czemu mogę zbierać informacje o poziomie zużycia przed przełączeniem wszystkich serwerów do tej konfiguracji. A to tylko SQL Server Express! : D - Upewnij się tylko, że dyski SSD zapewniają stały IOPS, ponieważ to kolejna rzecz, która robi ogromną różnicę (po prostu google). Dlatego wybrałem dyski SSD Intel DC (DataCenter).
źródło
Nie jest to odpowiedź, której prawdopodobnie szukasz w pierwszej części, ale: czy zastanawiałeś się nad przekazaniem jej do chmury? AWS może pozwolić ci zaspokoić większość powyższych potrzeb i zwiększyć siłę nabywczą bez konieczności zajmowania się sprzętem.
Druga część - sprzęt naprawdę zależy od zadań. Skłaniam się ku większej liczbie procesorów, gdy jestem w stanie wykonać niestandardową integrację CLR, ponieważ wtedy mogę zoptymalizować naprawdę równoległe rozwiązania problemów. Jednak przez większość czasu, jeśli lepiej jest mieć ustawione rozwiązania, uważam, że RAM i prędkość dysku twardego są największym wąskim gardłem, a drugi wydaje się być twoim przypadkiem. (Gdyby powyższy pomysł SSD byłby pomocny)
Bez żadnych prawdziwych statystyk z twojego serwera sugerowałbym, abyś spojrzał na niektóre rozwiązania buforujące, aby obniżyć zapisy (chyba że robisz jakieś logowanie przy zapisach lub rzeczy, które wymagają historii) i wkładasz dużo więcej pieniędzy na dyski twarde niż procesory. Serwer SQL jest całkiem dobry w równoległym korzystaniu z zapytań (jeśli są one napisane w tym celu), ale jeśli masz duże problemy z zapisywaniem, twój dysk twardy jest prawdziwym wąskim gardłem.
źródło