mmat

Przy zmianie kości 16 gb na 32 gb - dopłata jest 37 zł/mc netto od kości. Więc wymiana wszystkich zwiększy koszty serwera o 900 zł netto/mc.

Ogólnie chcemy zrobić taki test:

Serwerownia ma 2 wolne kości LRDIMM na stanie więc chcemy z serwera wyjąć wszystkie RDIMMy i włożyć te 2 LRDIMM-y.

Czyli sprawdzić czy 2 LRDIMM-y zadziałają w wersji 10-bay.

Tylko teraz pytanie czy jak 2 kości LRDIMM zadziałają - to czy można zakładać że 24 x LRDIMM też zadziała ???

@theONE

Dowiedziałem się że mamy tam 2 x 750W.

Ad 1. Nie wydaje mi się czy temperatura jest problemem - gdyż mamy tam raptem ok. 500 W, a te serwery występują z zasilaczami 1200 W - więc skoro taki zasilacz - to przewidziano też że takie obciążenie będzie możliwe.

Ad 2. Kości są dostępne, w serwerowni mogą je zamówić z hurtowni - tak więc to też nie jest problem.

A tak w ogóle - jaką platformę polecacie pod min. 10 x HDD i RAM >= 768 GB ?

Pytanie jest tylko takie - czy jak przetestujemy z 2 x 32 GB LRDIMM i takie zestawienie zadziała - to czy można zakładać że 24 x 32GB LRDIMM też będzie działać ?

Te serwery to już jak rosyjska ruletka

Dzięki za odpowiedź.

Więc chyba jedynym sposobem na sprawdzenie tego będzie przetestować taką konfigurację.

Nie wiem czym HP to argumentowało - po prostu powiedzieli że to nie będzie działać. Ale z tego co wiem to też nie było to dla nich takie jasne - gdyż z tego co mi w serwerowni mówili to w HP sami to konsultowali z iluś tam specjalistami i w końcu orzekli że nie.

Być może widząc nawet jakieś małe ryzyko że coś może działać niestabilnie - dla bezpieczeństwa powiedzieli że NIE - aby potem nie mieć z tego powodu problemów.

Chociaż jak dla mnie - taka decyzja jest niezgodna z publicznie dostępną specyfikacją tego serwera. W momencie zakupu kierowaliśmy się specyfikacją która wyraźnie mówiła że max. RAM to 768 GB (nie wspominając że to dotyczy tylko wersji 8-bay). A teraz mówią że to nie działa.

@SiXwishlist - dzięki wielkie za pomoc.

Obecnie mamy taką konfigurację:

HP Proliant DL360p Gen8

2 x Xeon E5-2643 v1 (3.30 GHz)

384 GB RAM, (24 x 16 GB RDIMM)

8 x SSD 480 GB, Intel 520/530

2 x HDD 1 TB

Jedyne co chcemy zamienić to 16GB-owe RDIMM-y na 32GB-owe LRDIMMy.

Czy to będzie mieć aż tak duży wpływ na pobór mocy ???

Różnica na 1 kości pamięci jest na poziomie 1,5 W - więc łącznie będzie może 35 W różnicy.

Nie bardzo rozumiem dlaczego to ma nie działać ???

Przecież ten serwer występuje nawet z wersjami zasilacza 1200 W - a my raptem mamy pobór w okolicy 500W.

Ponadto HP twierdzi że wersja z 8-bay by to obsłużyła, natomiast 10-bay już nie.

Czy 2 dodatkowe dyski o łącznym poborze 25W robią aż taką różnicę ?

Chyba że problem leży gdzieś indziej - mówiłeś coś o przerwaniach. Nie wiem nic na ten temat.

Możesz powiedzieć coś więcej ?

Z góry dzięki

Nie wiem tego na 100%, natomiast wiem że jest to zasilacz wyższy niż standardowy (pamiętam jak zmienialiśmy serwer na wersję 10-bay to był tam mocniejszy zasilacz).

Z tego co widzę to są tam dostępne opcje 460W, 750W i 1200W.

Tak więc mamy na pewno co najmniej 750W.

750W chyba wystarczy na taki serwer w zupełności.

Z tego to widzę to jedna kostka LRDIMM pobiera 4W. Więc nawet jak obsadzimy wszystkie sloty (24) - to zajmie niecałe 100W.

Z 10 napędów - 8 to SSD (pobierają max 5W/szt.) oraz 2 HDD (max. 10W/szt.). Więc napędy łącznie pobiorą max. 60W.

Grafiki nie ma. Procesory są też dwa (2 razy po 130W).

Płyta może weźmie z 50W.

Jak wszystko dodamy to łącznie ok 500W.

Tak więc jeszcze spory zapas zostaje.

A zawsze w razie czego można zmienić zasilacz na 1200W.

Ale właśnie w specyfikacji serwera nic o tym nie pisze:

http://www8.hp.com/h20195/v2/GetPDF.aspx/c04128242.pdf

Podają że można wkładać RDIMM, LRDIMM, UDIMM.

Wszystko jest niby ok, tylko w wersji 10-bay HP mówi że się nie da.

Co najdziwniejsze - to wersja 10-bay od 8-bay różni się tylko frontem serwera. Płyta główna jest ta sama.

Witam Wszystkich,

Mam taki problem:

Posiadam serwer HP Proliant DL360p Gen8 wersja z 10 miejscami na napędy (10 SFF Drive Bay).

Obecnie są w nim zamontowane kości pamięci 16 GB. Chcemy jednak przejść na moduły LRDIMM 32 GB - aby zwiększyć ilość pamięci RAM. W serwerowni próbowali zamówić kości w HP, jednakże HP twierdzi że kości LRDIMM NIE będą współpracować z tym serwerem (z wersją 10-bay).

Wydaje mi się to dość dziwne.

Mówią że LRDIMM by działały z wersją standardową 8-bay.

Natomiast twierdzą, że w wersji 10-bay NIE będą działać.

Jaki wpływ na pamięć RAM mogą mieć dodatkowe 2 miejsca na napędy ?

Czy HP ma w tym przypadku rację ?

Czy kości LRDIMM 32GB na pewno nie będą działać z wersją 10-bay ?

Z góry dziękuję za wskazówki i pomoc

Dzięki za wyjaśnienia.

Co do endurance to chyba nie jest taki słaby.

Obecnie używamy dysków serii 520/530, które mają Endurance na poziomie 36 TBW (20 GB/day over 5 years).

Wskaźnik "Wearout Indicator" nasze dyski wciąż mają teraz na poziomie 85% (tzn. 15% zużycia dopiero).

Z tego co widzę to seria 750 ma endurance 127 TBW (70 GB/day over 5 years).

Czyli wychodzi 3,5 raza większy od serii 5xx.

W zupełności nam to wystarczy.

Ok - dzięki za info.

Podpytam ich o to

Wow - dzięki za błyskawiczną odpowiedź

W sumie 4 takie dyski już powinny wystarczyć.

Ale patrząc przyszłościowo może być zapotrzebowanie na więcej.

My posiadamy wersję DL360p gen8 z 10 x SFF SATA/SAS/SSD Hot Pluggable Hard Drives i dwoma procesorami.

Dzięki za przesłany przez Ciebie link do specyfikacji - ale ciężko z niej wyczytać łączną łączną ilość gniazd PCI-E...

Strasznie zawile jest to opisane

Witajcie,

Mam takie krótkie pytanie:

Posiadam (tzn. dzierżawię serwer HP Proliant 360p gen8.

Obecnie używamy dysków SSD Intel serii 520/530.

Ze względu na wydajność rozważamy możliwość migracji na dyski Intel SSD 750 na interfejsie PCI-Express:

http://www.intel.pl/content/www/pl/pl/solid-state-drives/solid-state-drives-750-series.html

Czy ktoś może mi powiedzieć - jaką ilość takich dysków mogę zamontować w tym serwerze ?

Z góry dziękuję i pozdrawiam,

Użycie cpu jest liczone tak samo - nic się nie zmienia.

Nie jest stałe bo zwykle ilość uruchamianych procesów, dane które są przetwarzane, czy same skrypty/programy się zmieniają.

W tym przypadku może być np spam na skrzynce w jednym dniu albo maile same większe albo jeszcze coś innego i wynik się zmienia. Jest różnie to nie znaczy, że źle. Punkty są używane też przez inne procesy na koncie - nie tylko cron. Ftp, email itd. też.

Ad 1. "Użycie CPU jest liczone tak samo - nic się nie zmienia."

To jak możemy wytłumaczyć że jedynie zmiana planu z medium na platinium spowodowała zmniejszenie ok. 10-krotne zużywanych punktów ? Ruch pozostał taki sam - podobna ilość odwiedzin, maili, etc.

Teraz już niestety nie mamy dostępu do statystyk historycznych - gdyż prohost umożliwia dostęp tylko do ost. m-ca.

Ad 2. "Nie jest stałe bo zwykle ilość uruchamianych procesów..."

W panelu możemy sprawdzić "Statystyki PHP" i tam dokładnie widać który skrypt ma jaki udział w całym użyciu CPU. Skrypt w CRON-ie o którym mówię zajmuje 70-80% całości.

Ad 3. "dane które są przetwarzane, "

W zasadzie jedynym czynnikiem decydującym o obciążeniu jest ilość przychodzących maili.

Codziennie jest ona podobna - od kilku-kilkunastu w weekendy do kilkudziestu w dni robocze.

Niestety ale Pana argument jest nietrafiony - gdyż jak widać na załączonym wykresie 27. marca w niedziele Wielkanocną - zużycie CPU osiągnęło maksymalny peak (22 pkt.). Paradoksalnie był to dzień wolny i świąteczny - w którym przyszło jedynie kilka maili. Był to dzień o rekordowo niskim przetwarzaniu danych - ale w prohoscie ma on rekordowo wysokie zużycie CPU.

Ad 4. "same skrypty/programy się zmieniają"

Od początku używamy tej SAMEJ wersji osTicketa - nie aktualizujemy jej - gdyż została ona lekko zcustomizowana pod nas i gdybyśmy ją aktualizowali - to utracilibyśmy naszą customizację.

Witam,

Mam takie pytanie. Powiedzmy, że chcę wycenić serwis internetowy, który daje rocznie X przychodu, Y zysku, a roczna progresja przychodu/zysku to Z % (rok do roku), plus ewentualnie znamy jeszcze kilka innych kluczowych parametrów.

Czy ktoś kto ma doświadczenie w tym zagadnieniu - może podać jakiś ogólny wzór stosowany do wyceny serwisów internetowych. Zdaję sobie sprawę z tego, że do dokładnej wyceny jest potrzebna dokładna znajomość większej ilości szczegółów - ale zapewne na podstawie takich fundamentalnych wskaźników da się przynajmniej OSZACOWAĆ przybliżoną wartość serwisu.

Czyli chodzi mi o wzór typu: Wartość = 3 * Y * (100% + Z)

Czy może ktoś podać takie wzory/metody oszacowań jakie się powszechnie stosuje ?

Z góry dzięki za pomoc

Dzięki za propozycje.

Temat już jest trochę nieaktualny.

W związku z coraz niższymi cenami kości 32GB - doszliśmy do wniosku że taniej będzie w obecnym serwerze (24 DIMM) zamienić kości 16 GB na 32 GB co da łącznie 768 GB RAM.

Ok, ma - być może to było przyczyną. Choć dziwne jest to że jeszcze nigdy nie zauważyłem takiego efektu. Niemniej dzięki za pomoc

Z tego co widzę to ten model CPU (Xeon E5-2643) nie ma SpeedStep.

RAID jest HW. Zresztą nawet synchronizacja RAID-a nie spowodowała by że nagle sshd zaczeło brać 30% rdzenia.

Niestety już nie wrzucę ponieważ problem sam się rozwiązał. Zużycie spadło do poziomu normalnego.

Natomiast - tak jak pisałem - tu nie chodziło o konkretny proces - gdyż wszystkie wydały się zajmować więcej CPU (java, postgres, sshd). To sshd mnie dziwiło - wyglądało jakby był jakiś atak - ale w logach nie widać było żadnych prób logowań. Chyba że ktoś robił same TCP sync-e.

Zauważyłem dzisiaj wysokie zużycie CPU na serwerze dedykowanym. Zarówno uptime, jak i top pokazują spore zużycie (load dochodzi do 2-3 lub więcej).

Najdziwniejsze jest to, że to nie jest wina jakiegoś konkretnego procesu.

Wygląda jakby wszystkie procesy na serwerze zaczęły zabierać więcej CPU niż zwykle. Nawet zwykły sshd zabiera ponad 30% rdzenia (a to jest Xeon E5-2643 3.30 GHz).

Ten serwer używam już ok półtorej roku, żadnych problemów z nim nie było. Ostatnio NIE były także dokonywane żadne zmiany w konfiguracji czy aplikacjach.

Czy ktoś ma może jakieś pomysły lub sugestie ?

Z góry dzięki.

Osobiście nie miałem do czynienia z bazami No-SQL. SQL-a używam od wieków i on naprawdę baardzo szybko działa - pod warunkiem że:

- wiesz co robisz, wiesz jak optymalnie napisać zapytanie

- masz odpowiednią strukturę bazy i indeksy,

- odpowiednio skonfigurowałeś serwer - w przypadku postgresa to jest bardzo ważne,

- no i oczywiście chodzi to na odpowiednim sprzęcie

Niestety zaczynając projekt lata temu - nikt nie przewidywał że rozrośnie się on do takich rozmiarów. Obecnie przepisanie warstwy danych z użyciem MapReduce, partycjonowania - zajęło by sporo czasu - więc znacznie tańsza będzie inwestycja w hardware

Natomiast gdybym miał dzisiaj zmieniać architekturę - to bym nie wykorzystywał żadnej bazy - tylko napisał własną - idealnie dostosowaną do tego projektu - cholernie szybką i rozproszoną. Coś podobnego na kształt Terracota BigMemory - ale szybsze

Montowałem tylko 1 bazę ponad 1TB i uruchamialiśmy to na.... Mongo! Potem przejście na CouchDB ze względu na widzi mi się deweloperów tamtej aplikacji.

Nie wyobrażam sobie skalowania do takich rozmiarów typowego SQLa, bo np. joiny i transakcje były by dość zaawansowanymi operacjami.

Edit:
MapReduce to potęga w takich przypadkach.

Zdziwiłbyś się jak szybko działają joiny SQL-owe pod warunkiem że właściwie je wykonujesz (punkty napisane przeze mnie powyżej).

Yahoo ma bazy na postgresie do 2 PB (tak PetaBajty).

http://www.computerworld.com/s/article/9087918/Size_matters_Yahoo_claims_2_petabyte_database_is_world_s_biggest_busiest?taxonomyId=18&intsrc=hm_topic

Wygląda mi to, na coś w deseń BI.

Dokładnie.

https://wiki.postgresql.org/wiki/Postgres-XC to jest jedna z możliwości, ale nie wiem czy wspiera wszystko czego wymaga Twoja aplikacja.

 

Rozumiem, że po stronie aplikacji i bazy optymalizacja już zrobiona i nie da się wcześniej danych agregować i raportować do osobnych zasobów, żeby odpytywać już mniejszy zestaw danych?

Już jakiś czas temu widziałem ten projekt - ale jakoś nie zainteresowałem się nim wtedy.

A tak z ciekawości zapytam - używasz go ?

Tak - wszelki możliwy preprocessing jest oczywiście wykonywany. Niestety w przypadku większości zapytań nie da się go wykorzystać (zapytania używają wiele różnych kombinacji kryteriów dot. wielu pól).

Widzę że jest też HP Proliant DL585p Gen7 z 48 slotami pod Opterony.

Tak, do 32 slotów: http://www.supermicro.nl/aplus/memory/aplus_memory_support.cfm?pname=H8QG7/i(%2B)-LN4F

 

Tak z ciekawości, co będzie pracować na tak dużej ilości pamięci ?

U nas pojedynczy serwer fizyczny wykorzystał max 128GB bez wirtualizacji.

Baza PostgreSQL obecnie ok 500 GB - docelowo będzie więcej.

Jest dużo zapytań, ale co ważniejsze - pojedyncze zapytanie może obejmować nawet 10-20% całej objętości bazy. Stąd system jest bardzo RAM-hungry

Czasami nawet zdarzają się zapytania agregujące które mielą prawie całą bazę (prawie wszystkie rekordy).

Zależy jakie są zapytania itd. Jeżeli chodzi na przykład o generowanie raportów itd, to zawsze można użyć coś w typie klastra Hadoop oraz np. Hive czy Shark i na tym wykonywać zapytania, wtedy można rozbić na wiele low-endowych maszyn.

Czy możesz zaproponować jakieś rozwiązanie które pozwala PRZEŹROCZYŚCIE skalować postgresa na wiele maszyn ?

(mam na myśli przeźroczyście dla aplikacji która korzysta z bazy)