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).