🚀 go-pugleaf

Użytkownik Pawel Z. napisał:

> tyle, ze ten caly "klaster" w MySQL wymaga pomieszczenia calej
> bazy w pamieci... wiec znow slabo...

Masz na mysli ten standardowy klaster z MySQL AB. Istnieja rowniez inne 
mozliwosci. Ten o ktory pisalem jest zaimplementowany w warstwie 
aplikacji, przy wykozystaniu standardowej funkcjonalnosci replikacji.

> 
>>> z reszta i tak wiele zalezy od ilosci pamieci jaka system jest
>>> w stanie zaalokowac dla procesu... tak a propos, ile linux moze?
>>> 4GB?
>>
>>
>>
>> To zalezy. Na 32 bitowym systemie to z wiadomych powodow bedzie 4GB 
>> (lub nawet 3, nie pamietam teraz dobrze). Na x86_64 (przy zalozeniu ze 
>> proces jest rowniez skopilowany na x86_64) granica jest chyba 2TB.
> 
> 
> chcialbym to zobaczyc... ms tez twierdzi, ze potrafo obsluzyc
> 64 procesory itd...

Nie przesadzaj, gdzie mialby byc problem w przypadku systemu 64bitowego? 
Tu nie trzeba uzywac zadnych trickow zeby adresowac powyzej 4GB...

> 
>> W przypadku MySQL znaczenie ma raczej sama obecnosc pamieci w systemie 
>> niz mozliwosc jej alocowania przez process. Index cache i query cache 
>> nie powinny byc zbyt duze (z tych samych powodow co na Oracle), 
> 
> 
> nie jestem administratorem baz danych, wiec nie bede sie wypowiadal,
> ale jak widze co sie dzieje w systemach, ktorymi zajmuje sie
> i o co zebrza wlasnie admini baz danych to jest pamiec, i pamiec na 
> proces...

W przypadku Oracle ma to znaczenie. To wlasnie dlatego sa takie problemy 
  z Oracle na 32bitowych systemach z pamiecia powyzej 4GB. Pod linuxem 
trzeba wtedy ratowac sie /dev/shm, pod windows ponoc w ogole sie nie da...

Pozdro
Maciek

> 
> P.