1.2.
- Procesor* Intel Xeon E3-1270 v3 (4 rdzenie 3,5 GHz + 4 x HT) lub 6 rdzeni
- Pamięć* 32 GB (4 x 8GB 1600MHz DDR3 ECC)
- Procesor* 2 x Intel Xeon E5-2609v2 (4 rdzenie 2,5 GHz 10 MB CACHE)
- Pamięć RAM* 64 GB (8 x 8GB 1600MHz DDR3 ECC)
DYSKI (taka sama konfiguracja w obydwu przypadkach):
- 2 x Seagate ES 2 TB 7 200 obr./min - system i dane
- 2 x Intel SSD S3700 100GB (macierz RAID 1) - basa SQL
- 2 x Intel SSD S3700 100GB (macierz RAID 1) - log trans
Jedna z firm (po podaniu przeznaczenia serwera) zaproponowała dwa zestawy:
Nasuwa się parę pytań:
- bardziej wydajnie będzie pracować jeden procesor z większą ilością rdzeni czy dwa procesory z połowę mniejszą ilością rdzeni ?
- czy taki podział przestrzeni dyskowej poprawi wydajność serwera ? (tak ilość macierzy argumentuje sprzedawca)
- czy zaproponowane zestawy nie są trochę "przesadzone" ? czy mimo wszystko lepiej zainwestować i mieć spokój dłuższy czas ?
Co ta firma wie na temat działania programów Insertu ?Serwer wybieramy pod konkretną bazę danych ? Serwer który wydajnie obsługuje bezę programu X, nie będzie wydajnie obsługiwał bazy programu Y ?
Co ta firma wie na temat działania baz danych programów Insertu ?
nie sprawdziłeś jak zachowa się baza danych na pełnej wersji SQL'a - na podstawie takich informacji można tylko "zgadywać".Chyba gorzej chodzić nie będzie... ;)
- czy taki podział przestrzeni dyskowej poprawi wydajność serwera ? (tak ilość macierzy argumentuje sprzedawca)
Może coś tam poprawi, ale raczej tego nie zauważysz. Jestem też niezmiernie ciekaw "argumentów" sprzedawcy, może jakieś przykłady z życia ?
Insert GT nie został zaprojektowany do pracy wielowątkowej. Lepiej mieć wyższe taktowanie rdzeni niż ich większa liczbę.
na koniec ważna uwaga. Wielokrotnie było na forum, że oprócz sprzętu, można "tuningować" bazę danych. Przy niedużych nakładach można osiągnąć przyspieszenie, którego nie osiągniemy przez wymianę sprzętu nawet na taki za 20 tys. Wynika to z tego, że często kod programu jest "nieoptymalny".
Co ta firma wie na temat działania programów Insertu ?Serwer wybieramy pod konkretną bazę danych ? Serwer który wydajnie obsługuje bezę programu X, nie będzie wydajnie obsługiwał bazy programu Y ?
Co ta firma wie na temat działania baz danych programów Insertu ?
nie sprawdziłeś jak zachowa się baza danych na pełnej wersji SQL'a - na podstawie takich informacji można tylko "zgadywać".Chyba gorzej chodzić nie będzie... ;)
- czy taki podział przestrzeni dyskowej poprawi wydajność serwera ? (tak ilość macierzy argumentuje sprzedawca)
Może coś tam poprawi, ale raczej tego nie zauważysz. Jestem też niezmiernie ciekaw "argumentów" sprzedawcy, może jakieś przykłady z życia ?
Podobną "teorię" słyszałem od jednego z pracowników InsERT'u więc chyba coś w tym jest (tzn że trzymanie bazy i loga na oddzielnych dyskach jest korzystne dla wydajności)
Insert GT nie został zaprojektowany do pracy wielowątkowej. Lepiej mieć wyższe taktowanie rdzeni niż ich większa liczbę.
Zaraz, zaraz... Przecież GT instalujemy na końcówce i przez sieć wysyłamy zapytania do serwera bazy SQL - i to on (jego wersja) decyduje o tym jakie zasoby serwera zostaną użyte. Źle mysle?
na koniec ważna uwaga. Wielokrotnie było na forum, że oprócz sprzętu, można "tuningować" bazę danych. Przy niedużych nakładach można osiągnąć przyspieszenie, którego nie osiągniemy przez wymianę sprzętu nawet na taki za 20 tys. Wynika to z tego, że często kod programu jest "nieoptymalny".
Przeglądałem forum i owszem często pojawia się wzmianka o tym że bazę da się przyśpieszyć, ale po za radą "zrób odbudowę indeksów" niczego konkretnego nie widziałęm chyba ...
Osobiście jestem zdania, że rozwiązania dobiera się do potrzeb i jak zrozumiałem tego oczekuje autor wątku. Wiele razy widziałem wypasiony serwer, który nie jest wykorzystywany, a pracownicy dalej męczą się na 10-letnich komputerach...
Co ta wypowiedź miała wnieść do wątku ? Według mnie nie warto wydawać kilkanaście tysięcy zł jeśli nie mamy pewności, że przyniesie to oczekiwane korzyści, a pełny SQL często nie jest rozwiązaniem problemu. Jest to też element, który bez problemu można dokupić jeśli zajdzie taka potrzeba.Piszemy o >8 Gb ramu, a o ile dobrze pamiętam express wykorzystuje jedynie 1 Gb, więc przy 25 użytkownikach o których pisał pytający chyba możemy założyć w "ślepo" że pełna wersja jednak przyśpieszy (wykorzystując więcej pamięci operacyjnej ?)
Czytaj z odrobiną zrozumienia... Czy ja gdzieś napisałem, że to nie jest korzystne ?
Źle myślisz... Serwer SQL to tylko narzędzie, które robi to co mu każemy, jeśli jest wykorzystywane niepoprawnie to potrafi zużyć 10x, 100x, 1000x lub więcej zasobów niż to jest potrzebne do wykonania danej operacji. Ten sam wynik można uzyskać na wiele różnych sposobów, a programy Insertu zostały napisane tak, że zapytania wykonują się w jednym wątku i czym szybszy rdzeń tym wykonanie będzie szybsze...
Nie pamiętam już ile razu podawałem konkretne rozwiązanie jakiem jest "optymalizacja", jeden z wątków: http://www.forumsubiekta.pl/subiekt/poprawa-wydajnosci-poprzez-zmiane-domyslnej-lokalizacji-plikow-serwera-ms-sql/msg25646/#msg25646 (http://www.forumsubiekta.pl/subiekt/poprawa-wydajnosci-poprzez-zmiane-domyslnej-lokalizacji-plikow-serwera-ms-sql/msg25646/#msg25646).
Co ta wypowiedź miała wnieść do wątku ? Według mnie nie warto wydawać kilkanaście tysięcy zł jeśli nie mamy pewności, że przyniesie to oczekiwane korzyści, a pełny SQL często nie jest rozwiązaniem problemu. Jest to też element, który bez problemu można dokupić jeśli zajdzie taka potrzeba.Piszemy o >8 Gb ramu, a o ile dobrze pamiętam express wykorzystuje jedynie 1 Gb, więc przy 25 użytkownikach o których pisał pytający chyba możemy założyć w "ślepo" że pełna wersja jednak przyśpieszy (wykorzystując więcej pamięci operacyjnej ?)
Czytaj z odrobiną zrozumienia... Czy ja gdzieś napisałem, że to nie jest korzystne ?
Ok, nie napisałeś, ale wydawało mi się że dość ironicznie podszedłeś do tego argumentu sprzedawcy, stąd ten komentarz (jednak teraz widzę że sam proponujesz taki podział w jednym ze sw+oich postów do którego link podałeś).
Przy jednym biednym dyszczku tależowym, małej bazie danych i zapewne simple recovery model raczej nic to nie da - jak sprawdzisz daj znać.
Źle myślisz... Serwer SQL to tylko narzędzie, które robi to co mu każemy, jeśli jest wykorzystywane niepoprawnie to potrafi zużyć 10x, 100x, 1000x lub więcej zasobów niż to jest potrzebne do wykonania danej operacji. Ten sam wynik można uzyskać na wiele różnych sposobów, a programy Insertu zostały napisane tak, że zapytania wykonują się w jednym wątku i czym szybszy rdzeń tym wykonanie będzie szybsze...
To ja jednak czegoś nie rozumiem... :/
Skoro wszystkie zapytania wykonują się w jednym wątku to dlaczego włączają na jednej końcówce zapytanie które będzie się liczyło kilka minut (specjalnie źle napisane), na innych końcówkach (czy nawet w kopii programu na tym stanowisku) można swobodnie pracować?
Nie pamiętam już ile razu podawałem konkretne rozwiązanie jakiem jest "optymalizacja", jeden z wątków: http://www.forumsubiekta.pl/subiekt/poprawa-wydajnosci-poprzez-zmiane-domyslnej-lokalizacji-plikow-serwera-ms-sql/msg25646/#msg25646 (http://www.forumsubiekta.pl/subiekt/poprawa-wydajnosci-poprzez-zmiane-domyslnej-lokalizacji-plikow-serwera-ms-sql/msg25646/#msg25646).
Ok, chodziło mi o to, że na forum nie ma "gotowców" (choć rozumiem że to chleb serwisantów ;) ), a na przykład ten przypadek który podawałeś (modyfikacja spSub_CenyPoziom_14 i indeksów) jest chyba uniwersalny (tzn Twoje rozwiązanie zadziałało by również u innych - swoją drogą nie rozumiem czemu InsERT nie zadba o optymalizację tego typu rzeczy (o ile rozbudowa indeksów = zwiększenie rozmiaru bazy), to optymalizacja procedur chyba niczemu nie grozi ?).
dyski:
HD SATA 6G 500GB 7.2K HOT PL 2.5'' BC x 2 w RAID 1 - system
SSD SATA 6G 120GB ReadIntensive 2.5' H-P x 4 w RAID 10 - baza danych
"gołym okiem" widać zmiany na lepsze, program na końcówkach działa dużo szybciej.
Natomiast zużycie pamięci przez proces sqlservr.exe wynosi ok 15 GB.
Z jakiej konfiguracji sprzętowej się przesiadaliście bo nie wiadomo do czego porównać "odczucia" ?Wcześniejszy sprzęt (w wielkim skrócie):
Tego wyboru kompletnie nie rozumiem :( Ale jak już sprzęt jest to chętnie zobaczyłbym wyniki testów z obu macierzy.Dlaczego tak uważasz ? W przypadku bazy chodziło głownie o 1. niezawodność / bezpieczeństwo 2. szybkość działania
Po takiej inwestycji powinno być więcej entuzjazmu ;)Dużo więcej entuzjazmu było ze strony dziewczyn pracującej na tym serwerze :).
Przy waszej bazie to zdecydowanie za dużo, sprawdź ile z tego rzeczywiście jest wykorzystywane przez bazę danych. Jaki rozmiar ma baza danych ?Szczerze mówiąc sam się zdziwiłem użyciem pamięci... A w jaki sposób można sprawdzić to o czym pisałeś?
Poza tym ode mnie plus za podzielenie się doświadczeniem.Choć tyle mogę zrobić dla tego niezastąpionego forum - inni (w tym oczywiście Ty) robią dużo dużo więcej ;).
Tego wyboru kompletnie nie rozumiem :( Ale jak już sprzęt jest to chętnie zobaczyłbym wyniki testów z obu macierzy.Dlaczego tak uważasz ? W przypadku bazy chodziło głownie o 1. niezawodność / bezpieczeństwo 2. szybkość działania
Sprecyzuj proszę jakie testy masz na myśli, zrobię i wrzucę wyniki.
Przy waszej bazie to zdecydowanie za dużo, sprawdź ile z tego rzeczywiście jest wykorzystywane przez bazę danych. Jaki rozmiar ma baza danych ?Szczerze mówiąc sam się zdziwiłem użyciem pamięci... A w jaki sposób można sprawdzić to o czym pisałeś?
Plik bazy danych ma ~10GB.
Odpowiem pytaniem na pytanie... Dlaczego taki wybór ? Porównywałeś "praktyczną różnicę w wydajności w programach Insertu" między: RAID10 na 4 dyskach talerzowych, RAID 1 na 2 dyskach SSD i RAID 10 na 4 dyskach SSD ?Szczerze mówiąc nie.
DECLARE @total_buffer INT;
SELECT @total_buffer = cntr_value
FROM sys.dm_os_performance_counters
WHERE RTRIM([object_name]) LIKE '%Buffer Manager'
AND counter_name = 'Total Pages';
;WITH src AS
(
SELECT
database_id, db_buffer_pages = COUNT_BIG(*)
FROM sys.dm_os_buffer_descriptors
--WHERE database_id BETWEEN 5 AND 32766
GROUP BY database_id
)
SELECT
[db_name] = CASE [database_id] WHEN 32767
THEN 'Resource DB'
ELSE DB_NAME([database_id]) END,
db_buffer_pages,
db_buffer_MB = db_buffer_pages / 128,
db_buffer_percent = CONVERT(DECIMAL(6,3),
db_buffer_pages * 100.0 / @total_buffer)
FROM src
ORDER BY db_buffer_MB DESC;| db_name | db_buffer_pages | db_buffer_MB | db_buffer_percent |
| Baza__PL__2014 | 1163237 | 9087 | NULL |
| Baza__UK__2013 | 82356 | 643 | NULL |
| naklejki | 32023 | 250 | NULL |
| uk | 17440 | 136 | NULL |
| tempdb | 15992 | 124 | NULL |
| Test | 13224 | 103 | NULL |
| Resource DB | 3008 | 23 | NULL |
| Baza_BACK | 1795 | 14 | NULL |
| msdb | 616 | 4 | NULL |
| master | 414 | 3 | NULL |
| model | 182 | 1 | NULL |
| ReportServer$INSERTGT2 | 236 | 1 | NULL |
| ReportServer$INSERTGT2TempDB | 190 | 1 | NULL |
To co pokazuje załącznik z początku wątku ? Wynika z niego, że danych jest nie całe 3GB, gdzie jest pozostałe 7GB ?