🚀 go-pugleaf

Dnia 22.12.2011 Servant <freinag@cs.cy> napisał/a:
> No i stanęło na tym że robimy RAID programowo.
> Prezes nie chce ryzykować ewentualnego padu dedykowanej karty.
> ;-)
>
> Mam w tej chwili 2GB RAM. Chcę dokupić jeszcze 8GB.
> Co do portów SATA II, to na płycie mam 6 sztuk
> (INTEL S5000VSA)
> Teraz mam pytamie:
> Przeinstalować system na 64 bit, czy zostawic 32?
> Na serwerze działa samba, firebird i poczta (postfix, dovecot)
> tylko wewnątrz LAN.
> Dystrybucja Slackware 13.0

No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
usług.

Sergiusz Rozanski napisał:

> > Przeinstalować system na 64 bit, czy zostawic 32?
> > Na serwerze działa samba, firebird i poczta (postfix, dovecot)

>  No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
>  szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
>  usług.

A któraś z nich będzie wymagała alokacji > 2GB RAMu?

Bo jeśli będą to procesy typu "male a dużo" (dovecot, postfix, samba,
apache) to 64 bity nie mają sensu, a wręcz przeciwnie - różnice
architektoniczne spowodują, że procesów zmieści się w pamięci mniej,
niż na systemie 32 bitowym, w efekcie zostanie mniej RAMu na cache,
i będzie gorzej.

--
Daniel Podlejski

Dnia 23.12.2011 Daniel Podlejski <underley@underley.eu.org> napisał/a:
> Sergiusz Rozanski napisał:
>
>> > Przeinstalować system na 64 bit, czy zostawic 32?
>> > Na serwerze działa samba, firebird i poczta (postfix, dovecot)
>
>>  No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
>>  szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
>>  usług.
>
> A któraś z nich będzie wymagała alokacji > 2GB RAMu?
>
> Bo jeśli będą to procesy typu "male a dużo" (dovecot, postfix, samba,
> apache) to 64 bity nie mają sensu, a wręcz przeciwnie - różnice
> architektoniczne spowodują, że procesów zmieści się w pamięci mniej,
> niż na systemie 32 bitowym, w efekcie zostanie mniej RAMu na cache,
> i będzie gorzej.

Ale zaletą 64-bit jest nie tylko zasięg pamięci >2GB ale (wg mnie
głównie) 2x tyle rejestrów, co oznacza że kompilacje 64-bitowe się mniej
zrzucają do ram, a w efekcie mogą chodzić szybciej (w końcu rejestry to
najszybsza pamięć w kompie).

Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
w celu np energooszczędności czy wydajności) - tym będzie łatwiej.

Sergiusz Rozanski napisał:

>  Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>  w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>  tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>  poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>  pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>  w celu np energooszczędności czy wydajności) - tym będzie łatwiej.

Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
który będzie 4 razy tańszy.

Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.

A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.

--
Daniel Podlejski

Dnia 23.12.2011 Daniel Podlejski <underley@underley.eu.org> napisał/a:
> Sergiusz Rozanski napisał:
>
>>  Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>>  w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>>  tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>>  poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>>  pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>>  w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
>
> Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
> który będzie 4 razy tańszy.

No a 64GB to max dla PAE.

> Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
> jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.

Nie na siłę ale ...

> A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
> 2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.

... ten wątek to kontynuacja innego dot. dysków i mirrorów, na tym serwerze
zapowiada się mała rewolujca, więc przy okazji taki upgrade nie będzie
wielkim obciążeniem - chodzi o kilka usług i na 100% zaplanowane ich
wylaczenie, a w przyszłości jak bedzie ich naście - będzie trudniej
szczególnie wygospodarować nowy stoptime.

Ja nowe instalacje robie już tylko na 64, biorę pod uwagę przyszłe migracje i
zbędny z tym zmarnowany czas. Nie zapominajmy że te instalacje są raczej
długowieczne, fsy są przenoszone z kompa na komp, z dysku na dysk, mam
instalacje pamiętające instalke z debian-hamm - bez apt :)

>  Ja nowe instalacje robie już tylko na 64, biorę pod uwagę przyszłe migracje i
>  zbędny z tym zmarnowany czas. Nie zapominajmy że te instalacje są raczej
>  długowieczne, fsy są przenoszone z kompa na komp, z dysku na dysk, mam
>  instalacje pamiętające instalke z debian-hamm - bez apt :)

Offtopicując - jeszcze dwa lata temu robiłem/myślałem podobnie.

Teraz wolę mieć instalację i konfigurację oskryptowaną w chefowych
cookbookach i martwić się tylko o backup danych krytycznych dla
działania usług. Dzięki temu mogę mieć "kopię" serwera gotową w
kilka(naście) minut. Bardzo przydatne w wielu sytuacjach, nie
tylko awaryjnych.

(z tymi kilkoma minutami to nie ściema - uruchomienie kolejnego
serwera frontendowego na EC2 z chefa rzeczywiście tyle trwa, ale
to już totalny off-topic)

--
Daniel Podlejski

Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> napisa�(a) w
wiadomosci do grupy dyskusyjnej

> No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
> szybciej si� upgradujesz tym mniej roboty w przysz�o�ci - jak dojdzie
> us�ug.

W�a�ciwie, to razem 10GB b�dzie. P�yta ju� ma dwa czterordzeniowe
XEONy.
Na razie si� nudz� ;-)

--
Pozdrawiam
Servant

Daniel Podlejski <underley@underley.eu.org> napisa�(a) w wiadomosci do
grupy dyskusyjnej

> Bo je�li b�d� to procesy typu "male a du�o" (dovecot, postfix, samba,
> apache) to 64 bity nie maj� sensu,

W�a�nie. Moje my�lenie te� t� �cie�k� pod��a�o. Ale Sergiusz R. r�wnie�
swoje racje ma.

--
Pozdrawiam
Servant

Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> napisa�(a)
w wiadomosci do grupy dyskusyjnej

> ... ten w�tek to kontynuacja innego dot. dysk�w i mirror�w, na tym
> serwerze zapowiada si� ma�a rewolujca, wi�c przy okazji taki
> upgrade nie b�dzie wielkim obci��eniem - chodzi o kilka us�ug i na
> 100% zaplanowane ich wylaczenie, a w przysz�o�ci jak bedzie ich
> na�cie - b�dzie trudniej szczeg�lnie wygospodarowa� nowy stoptime.
>

Teraz jestem w kropce co do 64 bit. Najbardziej obawiam si� samby, bo
mam wersj� 3.2.7. Nowsze nie chcia�y dzia�a�. Walczy�em z tym w sunie
kilkana�cie godzin, ale poleg�em. Trzeba by szuka� starych �r�de� i
kompilowa� na 64 bit. Paczki slackware_64 s� ju� nowsze.
A na t� "ma�� rewolucj�" musi mi wystarczy� sobota i niedziela gdzie� w
pierwszewj dekadzie stycznia.

--
Pozdrawiam
Servant

On 12/23/2011 12:37 PM, Sergiusz Rozanski wrote:
> Dnia 23.12.2011 Daniel Podlejski <underley@underley.eu.org> napisał/a:
>> Sergiusz Rozanski napisał:
>>
>>>  Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>>>  w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>>>  tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>>>  poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>>>  pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>>>  w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
>>
>> Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
>> który będzie 4 razy tańszy.
>
> No a 64GB to max dla PAE.
>
>> Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
>> jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.
>
> Nie na siłę ale ...

OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
pamięci jest 2GB...

ein napisał(a):

>  OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
>  pamięci jest 2GB...

A gdzie ktoś z nas tak twierdzi? Mowa była o limicie alokacji pamięci
przez pojedynczy proces w systemie 32-bitowym (generalnie to jest to
trochę więcej niż 2GB, ale nie jest to 4GB wynikające teoretycznie z
32 bitów adresu).

--
Daniel Podlejski

Dnia 23.12.2011 ein <ein@no.spam> napisał/a:
> On 12/23/2011 06:55 PM, Daniel Podlejski wrote:
>> ein napisał(a):
>>
>>>  OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
>>>  pamięci jest 2GB...
>>
>> A gdzie ktoś z nas tak twierdzi? Mowa była o limicie alokacji pamięci
>> przez pojedynczy proces w systemie 32-bitowym (generalnie to jest to
>> trochę więcej niż 2GB, ale nie jest to 4GB wynikające teoretycznie z
>> 32 bitów adresu).
>
> No dobra, a skąd bierze się TEN limit dla wątku/procesu?

Z konstrukcji sposobu adresowania i w ogóle projektu cpu 32-bit. Posztukowano
to PAE aby taki cpu widział do 64GB (ale jako całość) i to wszystko. Limit dla
procesu pozostał. Nie wiem tylko czy pae było w 64bitowcach w tybie 32 czy
również były 32bitowe cpu z pae.

On 12/23/2011 06:55 PM, Daniel Podlejski wrote:
> ein napisał(a):
>
>>  OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
>>  pamięci jest 2GB...
>
> A gdzie ktoś z nas tak twierdzi? Mowa była o limicie alokacji pamięci
> przez pojedynczy proces w systemie 32-bitowym (generalnie to jest to
> trochę więcej niż 2GB, ale nie jest to 4GB wynikające teoretycznie z
> 32 bitów adresu).

No dobra, a skąd bierze się TEN limit dla wątku/procesu?

ein napisał(a):

>  No dobra, a skąd bierze się TEN limit dla wątku/procesu?

Z podziału na user-space i kernel-space. AFAIR proces może
zaalokować tylko tą część, która jest przeznaczona na userspace.

--
Daniel Podlejski

Dnia 23.12.2011 Servant <freinag@rcs.cy> napisa�/a:

> Teraz jestem w kropce co do 64 bit. Najbardziej obawiam si� samby, bo
> mam wersj� 3.2.7. Nowsze nie chcia�y dzia�a�. Walczy�em z tym w sunie

Ta wersja samby jest dziurawa. By�o uaktualnienie do 3.2.15 lub wy�szej
w nowszym wydaniu dystrybucji, ale to Twoja maszyna ...

> kilkana�cie godzin, ale poleg�em. Trzeba by szuka� starych �r�de� i
> kompilowa� na 64 bit. Paczki slackware_64 s� ju� nowsze.
> A na t� "ma�� rewolucj�" musi mi wystarczy� sobota i niedziela gdzie� w
> pierwszewj dekadzie stycznia.
>

panti <pantiusunto@zgotu.pl> napisa�(a) w wiadomosci do grupy
dyskusyjnej

> Ta wersja samby jest dziurawa. By�o uaktualnienie do 3.2.15 lub
> wy�szej w nowszym wydaniu dystrybucji, ale to Twoja maszyna ...

Zmobiliozowa�e� mnie.
B��d znalaz�em.
Dzi�ki.

--
Pozdrawiam
Servant

Daniel Podlejski <underley@underley.eu.org> writes:

> A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
> 2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.

Na tej tylko podstawie, jasne że nie.
Na podstawie tylko podanych informacji, będzie dokladnie obojętne jaka
wersja systemu będzie używana. Ktoś pisał że będzie "dużo małych
procesów" - ja myślę, że to będzie raczej "mało małych procesów".

Natomiast w ogóle system 64-bitowy może być wymagany przez bardzo
trywialne rzeczy. Np. ja ostatnio będę chyba musiał użyć x86-64 na
maszynce z Core 2 Duo ULV 1200 MHz + 1 GB RAM. Dlaczego? Bo jeden
z plików, taki o długości 35 GB, będzie musiał być mapowany w RAM.

Generalnie w przypadku normalnych, względnie współczesnych maszynek,
system 64-bitowy "nie gryzie" (pomijąc ew. problemy z 32-bitowymi
binariami, które nie mogą być np. bezpośrednio pluginami). System
32-bitowy, mimo że może być minimalnie bardziej (lub mniej) wydajny,
może się w ogóle nie nadawać do konkretnego zastosowania. Wniosek jest
IMHO prosty, należy polecać "w ciemno" wersję x86-64.

Wesołych Swiąt,
--
Krzysztof Halasa

Sergiusz Rozanski <write-only-with-spf@media-lab.com.pl> writes:

> Nie wiem tylko czy pae było w 64bitowcach w tybie 32 czy
> również były 32bitowe cpu z pae.

PAE było w 32-bitowych CPU od czasów chyba Pentium Pro.
--
Krzysztof Halasa

Daniel Podlejski <underley@underley.eu.org> writes:

> Z podziału na user-space i kernel-space. AFAIR proces może
> zaalokować tylko tą część, która jest przeznaczona na userspace.

Eee tam. Teraz to już nie ma praktycznego znaczenia, ale przez długi
czas dość popularny był split "4G/4G", który cała przestrzeń adresową
oddawał jednoczeście obu "częściom" (kosztem pewnych kombinacji
przy przechodzeniu między trybami user i kernel, oraz podczas np.
transferów z/do pamięci user space w trybie kernela).
--
Krzysztof Halasa

Krzysztof Halasa <khc@pm.waw.pl> napisa�(a) w wiadomosci do grupy
dyskusyjnej

> Wniosek jest
> IMHO prosty, nale�y poleca� "w ciemno" wersj� x86-64.

Witam
A w mojej konkretnej sytuacji co by� zastosowa�?

Ponadto mam jeszcze pytanie w kwestii technicznej.
Mam w tej chwili 3 dyski 1TB podzielone ka�dy na dwie r�wne partycje.
System w zasadzie le�y na oddzielnym dysku 250GB PATA (katalogi /home i
/opt zlinkowane na partycje dysk�w terabajtowych)
Kombinuj� tak: Kupuj� 3 nowe dyski 1TB.
Tamte 3 wypinam, Pod��czam nowe, formatuj� i tworz� raid.
Nast�pnie pod��czam kolejno dyski z danymi, kopiuje dane na macierz.
Po skopiowaniu dysk formatuj� i pod��czam do macierzy jako kolejny
czwarty i pi�ty.
Jeden dysk co mi zostanie pod��cz� oddzielnie i przeznacz� na kopie
Ma to szanse powodzenia?

--
Pozdrawiam
Servant

Servant <freinag@rcs.cy> writes:

>> Wniosek jest
>> IMHO prosty, należy polecać "w ciemno" wersję x86-64.
>
> Witam
> A w mojej konkretnej sytuacji co byś zastosował?

To co w każdej innej, tak jak napisałem wyżej. Chyba że są uzasadnione
argumenty by tego nie robić, ale (względnie) wypasiona maszynka +
niewielkie obciążenie nie są takimi argumentami.
Odwrotnie, maszynka całkowicie obciążona - można się zastanawiać.

> Mam w tej chwili 3 dyski 1TB podzielone każdy na dwie równe partycje.
> System w zasadzie leży na oddzielnym dysku 250GB PATA (katalogi /home i
> /opt zlinkowane na partycje dysków terabajtowych)
> Kombinuję tak: Kupuję 3 nowe dyski 1TB.
> Tamte 3 wypinam, Podłączam nowe, formatuję i tworzę raid.

Jaki dokładnie RAID?

> Następnie podłączam kolejno dyski z danymi, kopiuje dane na macierz.
> Po skopiowaniu dysk formatuję i podłączam do macierzy jako kolejny
> czwarty i piąty.
> Jeden dysk co mi zostanie podłączę oddzielnie i przeznaczę na kopie
> Ma to szanse powodzenia?

Tzn. rozumiem, że tak czy owak masz backup wszystkiego (istotnego
przynajmniej), bo informację na dyskach bardzo łatwo stracić, zarówno
jeśli się w nich ostro grzebie, jak i bez żadnego własnego udziału.

Myślę że to jest do zrobienia, ale najważniejsze jest dobre
zaprojektowanie docelowego rozwiązania.
--
Krzysztof Halasa

Krzysztof Halasa <khc@pm.waw.pl> napisa�(a) w wiadomosci do grupy
dyskusyjnej

> Jaki dok�adnie RAID?

RAID 5.
Trzy dyski pono� wystarcz� na pocz�tek.


--
Pozdrawiam
Servant

Servant <freinag@rcs.cy> writes:

> RAID 5.
> Trzy dyski ponoć wystarczą na początek.

No tak.

Jedyne co moge dodać, to to, że osobiście nie lubię RAIDów-5, i zamiast
nich stosuję praktycznie wyłącznie RAID-1 i RAID-10 (a czasem także
sam stripping bez redundancji ("RAID-0")).

Tzn. pewnie w przypadku dużych macierzy użyłbym RAID-5 lub 6, ale taka
"duża" macierz musiałaby mieć przynajmniej z 5 dysków (= 8 dysków
w RAID1+0 lub 10), tak na oko obecnie 8 albo np. 12 TB. Przy mniejszych
to się moim zdaniem, przy obecnych relatywnie niedużych cenach dysków,
nie opłaca.

Ale to tylko taka moja subiektywna opinia :-)
--
Krzysztof Halasa

Krzysztof Halasa napisał:

>  Jedyne co moge dodać, to to, że osobiście nie lubię RAIDów-5, i zamiast

+1 ;)

>  nich stosuję praktycznie wyłącznie RAID-1 i RAID-10 (a czasem także
>  sam stripping bez redundancji ("RAID-0")).

Pomysłem do rozważenia zamiast RAID-5 może być RAID-1E:
http://en.wikipedia.org/wiki/RAID_1E#RAID_1E

Da się zrealizować na bazie linuksowego RAIDu softwareowego.

--
Daniel Podlejski

Krzysztof Halasa <khc@pm.waw.pl> napisa�(a) w wiadomosci do grupy
dyskusyjnej

> taka
> "du�a" macierz musia�aby mie� przynajmniej z 5 dysk�w

W�a�nie tyle b�dzie mie� docelowo po zrzuceniu wszystkich danych z
dysk�w, kt�re "chodz�" teraz.

--
Pozdrawiam
Servant

> No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.

Nie wiem jak na 2GB RAM czy na 8GB ale na:
Na 64bitach 16GB RAM (bo pamięc tania jak barszcz), RAID-5 programowy 3xSATAII, kernel 3.2.13 śmiga tak że palce lizać.
Pliki do 2GB w 5 sekund zapis (keszuje) a większe 8GB pliki zapisuje z prędkością 160MBs a odczyt ~180MBs przy obciążeniu
maksymalnym chwilowym do 40% rdzenia, średnio ok 15% rdzenia. Rdzeni mam sporo więc pomijalne dla mnie obciążenie.

Nie bardzo tylko rozumiem akąd u ciebie dylemat nad 32 czy 64 bitami ?
Od wielu lat stosuję już 64bit i wszystko hula bezproblemowo i tylko raz się spotkałem z aplikacją (mrtg) która buntowała się z
działaniem na 64bitach. Po aktualizacji działa.
Pamiętaj o tym, że jak zainstalujesz 32bity to zapomnij o dokładaniu pamięci, tylko ok 3GB z hakim i nic ponadto, w zwiazku z czym
jakiekolwiek zastanawianie się dla mnie w 2011 czy 2012r nad wyborem wersji jest dla mnie śmieszny i oczywisty TYLKO 64bit.

Pozdrawiam.