To jest pytanie czysto teoretyczne. Powiedzmy, że mam aplikację wdrożoną na wielu serwerach.
- Moduł równoważenia obciążenia,
- Wiele / skalowalne serwery aplikacji
- (Pojedynczy) serwer bazy danych (na razie)
W dwóch pierwszych częściach wiem, czego szukać. Ale co z serwerem bazy danych? Jakiego sprzętu powinienem szukać?
- Czy częstotliwość procesora jest istotna dla serwera bazy danych?
- Czy istotne są procesory wielordzeniowe?
- Czy pamięć RAM jest ważniejsza niż procesor?
PS: Załóżmy, że wybrana baza danych to MySQL lub PostgreSQL.
mysql
postgresql
performance
Zenklys
źródło
źródło
Odpowiedzi:
W przypadku PostgreSQL moc procesora może być bardzo istotna, szczególnie jeśli dość wysoki procent aktywnego roboczego zestawu danych mieści się w pamięci RAM. Większość baz danych, z którymi pracowałem, przez większość czasu była głównym problemem wąskiego gardła. (Właśnie sprawdziłem vmstat na serwerze obsługującym witryny internetowe z milionami odwiedzin dziennie, w których znajduje się ponad 5 TB miejsca w bazie danych, i nigdy nie widziałem więcej niż 2% czasu oczekiwania na dysku, ale widziałem szczyt 12% czasu procesora użytkownika).
Ponieważ PostgreSQL jest oparty na procesach, każdy pojedynczy proces może działać tylko tak szybko, jak jeden rdzeń, ale w mieszance takiej jak na serwerze wspomnianym powyżej, z dużą liczbą małych żądań, najważniejszy jest całkowity procesor we wszystkich rdzeniach. Przy tej samej całkowitej mocy procesora PostgreSQL generalnie będzie lepiej z mniejszą liczbą szybszych rdzeni niż z wieloma wolniejszymi rdzeniami.
Aż do momentu, gdy wysoki procent twojego aktywnego zestawu danych jest buforowany, dodanie pamięci RAM zwykle pokazuje więcej huku za dolary niż dodawanie rdzeni. Po wystarczającym buforowaniu zmniejsza się korzyść z dodatkowej pamięci RAM i lepiej jest zwiększyć moc procesora.
Aby uzyskać więcej informacji na ten temat, ponieważ dotyczy PostgreSQL, nie sądzę, że istnieje lepsze źródło niż PostgreSQL 9.0 High Performance autorstwa Grega Smitha . (Pełne ujawnienie, byłem recenzentem technicznym książki, ale nie otrzymuję żadnych korzyści finansowych na podstawie sprzedaży).
źródło
Ściśle z perspektywy MySQL to bardzo obciążone pytanie
Podczas gdy szybszy procesor i płyta główna są świetne, inne przeszkody mogą przeszkadzać. Takie wąskie gardła obejmują:
Każda niewielka zaleta pomaga, ale muszę powiedzieć „ nie”, ponieważ szybkość procesora sama w sobie nie poprawia się we wspomnianych wąskich gardłach. W końcu, co dobrego może zrobić samochód wyścigowy Formuły 1, mając otwarty spadochron lub goryla o wadze 800 funtów za kierownicą?
Zależy to całkowicie od tego, którą wersję MySQL używasz. Wtyczka MySQL 5.1 InnoDB, MySQL 5.5 i XtraDB serwera Percona Server mają ustawienia, które MUSISZ PRAWIDŁOWO SKONFIGUROWAĆ, aby InnoDB miał dostęp do wszystkich rdzeni. Prawdziwa zachęta do zrobienia tego wynika z faktu, że niektóre starsze wersje MySQL LEFT UNCONFIGURED są szybsze niż nowsze wersje, jak omówiłem w moich poprzednich postach:
Dlatego jeśli nie chcesz konfigurować InnoDB do uzyskiwania dostępu do wszystkich procesorów, posiadanie wielu rdzeni nic nie kosztuje .
Och, tak, rzeczywiście. Konfiguracja pamięci MySQL wymaga konfiguracji
Żądanie za mało lub za dużo kombinacji tych rzeczy i MySQL wróci, by cię ugryźć. Szybszy procesor z MySQL niepoprawnie skonfigurowany dla pamięci RAM sprawia, że MySQL gryzie cię szybciej.
źródło
Mówiąc najprościej, potrzebujesz baz danych i pamięci RAM (opóźnienie + prędkość odczytu + prędkość zapisu) dla baz danych.
Wybór 4 lub 6 rdzeni lub 2,5 GHz vs 3 GHz nie jest tak naprawdę istotny (zakładam, że nie musisz wybierać pomiędzy P3-450 z 32 GB RAM lub najnowszym Xeon z 1 GB RAM).
Jeśli jesteś związany z procesorem, masz inne problemy (zły projekt, słabe indeksy, zamiana, serwer niepedykowany itp.)
źródło