Jaka partycja na dysku SSD

[markopolo 0]

WITAM,

 

posiadam 2 dyski SSD 128GB i 1 SATA 500GB i nie wiem na jakie partycje je przeznaczyć

jak podzielić dyski między partycje aby uzyskać jak największą optymalność

jaka partycja będzie najlepsza pod SSD aby serwer działa bardo szybko

home, tmp, /, var, swap, srv co umieścić na dysku SSD

 

prosze o jakiś sugestie

z góry dziękuje

[theONE 526]

nie podales informacji:

- co ma robic serwer

- jakie sa krytyczne aplikacje na serwerze

- jaki system

- czy uzywasz swapa

- ile masz ramu

- czy masz zewnętrzny backup i czy mozesz sobie do pewnego stopnia pozwolic na utrate danych

[markopolo 0]

serwer www około 200 domen,

chodzi o to żeby szybko się wczytywały,

system suse lub centOS

używam swapa

16GB ramu

backup będzie zew. nie mogę sobie pozwolić na utratę danych

[Miłosz 2311]

A ile zajmuje miejsca te 200 domen? Jeśli będziesz robić regularne backupy, np co 24h i nie zmartwi Cie pare godzin przestoju na wymianę dysku, to możesz spiąć ssd w raid 0.

[markopolo 0]

posiadam 2 dyski SSD 128GB i 1 SATA 500GB i nie wiem na jakie partycje je przeznaczyć

czy ktoś wie jaka partycja powinna być na SSD?

[malu 460]

Nie odpowiedziałeś na pytanie, jakie szacunkowo zużycie dysku przewidujesz/znasz dla tych 200 klientów.

Bo być może będziesz mógł ich pliki/skrypty umieścić na dysku SSD.

 

Zasadniczo warto oczywiście umieścić MySQL na SSD czyli odpowiedniego powinno to być /var/lib/mysql lub dla Debiana z DirectAdminem /home/mysql/. FS - według wymogów, jeżeli nie ma konkretnych to możesz kierować się w stronę ext4

Dodatkowo warto pomyśleć, aby wydzielić osobną partycję dla kolejki exima (O ile, akurat jego używasz), wtedy ścieżka /var/spool/exim. FS - ext2. Tutaj jednak nie koniecznie potrzebujesz dysku SSD, głównie chodzi o to, aby działało to pod ext2.

Oczywiście odrębna partycja dla /tmp, bo miło by było zabezpieczyć to paroma flagami. Filesystem ext2.

 

Oczywiście zadbać, aby wszędzie było flagi odpowiednie.

 

Nie odpowiedziałeś na pytanie, jakie szacunkowo zużycie dysku przewidujesz/znasz dla tych 200 klientów. Bo być może będziesz mógł ich pliki/skrypty umieścić na dysku SSD. Zasadniczo warto oczywiście umieścić MySQL na SSD czyli odpowiedniego powinno to być /var/lib/mysql lub dla Debiana z DirectAdminem /home/mysql/. FS - według wymogów, jeżeli nie ma konkretnych to możesz kierować się w stronę ext4 Dodatkowo warto pomyśleć, aby wydzielić osobną partycję dla kolejki exima (O ile, akurat jego używasz), wtedy ścieżka /var/spool/exim. FS - ext2. Tutaj jednak nie koniecznie potrzebujesz dysku SSD, głównie chodzi o to, aby działało to pod ext2. Oczywiście odrębna partycja dla /tmp, bo miło by było zabezpieczyć to paroma flagami. Filesystem ext2. Oczywiście zadbać, aby wszędzie było flagi odpowiednie.

 

Podaj jakieś konkretnie zużycie. Wtedy będzie można myśleć, jak to sensownie i bezpiecznie spiąć.

[Gość patrys]

/var/spool/exim. FS - ext2

czemu ?

partycja dla /tmp, bo miło by było zabezpieczyć to paroma flagami. Filesystem ext2.

Jak sama nazwa wskazuje powinno być w ramie, a ext2 to już kompletnie nie rozumiem

[malu 460]

czemu ?

 

Jak sama nazwa wskazuje powinno być w ramie, a ext2 to już kompletnie nie rozumiem

/tmp nie chciałem podawać w ramie, bo są różne kwiatki i różne rzeczy tam trzymają, a w przypadku co niektórych daemonów np. MySQL wychodzą później ciekawostki. Standardowo nie wszyscy myślą. Ale jeżeli chce to jak najbardziej może to podmontować jako ramdisk.

 

Dlaczego ext2, ze względu na wydajność, brak journaling. W zasadzie nie wiem jak wypada na tle ext4, bo tego nie sprawdzałem. Tudzież ext4 z wyłączonym journaling. W każdym razie ext2 na partycjach typu /tmp, znakomicie sobie radzi. Praktyka stosowana sto lat temu, jak i teraz. Więc, nie wiem dlaczego nie słyszałeś o czymś takim.

[Gość patrys]

/tmp nie chciałem podawać w ramie, bo są różne kwiatki i różne rzeczy tam trzymają, a w przypadku co niektórych daemonów np. MySQL wychodzą później ciekawostki. Standardowo nie wszyscy myślą. Ale jeżeli chce to jak najbardziej może to podmontować jako ramdisk.

Jakie kwiatki? Jak tylko pozwala na to ilość ramu zawsze montujemy katalog /tmp w ram.

Nawet do tego powstał system plików i nie widać przeciwwskazań, a jedynie plusy.

 

Dlaczego ext2, ze względu na wydajność, brak journaling. W zasadzie nie wiem jak wypada na tle ext4, bo tego nie sprawdzałem. Tudzież ext4 z wyłączonym journaling. W każdym razie ext2 na partycjach typu /tmp, znakomicie sobie radzi. Praktyka stosowana sto lat temu, jak i teraz. Więc, nie wiem dlaczego nie słyszałeś o czymś takim.

No nie stosujmy archaicznego systemu plików, to nie debian woody

Wydajność możesz uzyskać bardzo dobrą na ext4 ucinając księgowanie/bariery, jednak do tmp, uzywamy systemu plików tmpfs.

 

Tak do tematu, @markopolo pamiętaj że jeżeli SSD obsługują TRIM to użyj systemu plików który go wspiera np. ext4 montując z opcją "discard".

I nie rób nigdy swap/tmp na SSD.

[malu 460]

Jakie kwiatki? Jak tylko pozwala na to ilość ramu zawsze montujemy katalog /tmp w ram.

Nawet do tego powstał system plików i nie widać przeciwwskazań, a jedynie plusy.

 

No nie stosujmy archaicznego systemu plików, to nie debian woody

Wydajność możesz uzyskać bardzo dobrą na ext4 ucinając księgowanie/bariery, jednak do tmp, uzywamy systemu plików tmpfs.

Wszystko zależy od zdrowego rozsądku. W podanym przeze mnie przykładzie, wyobraź sobie partycje tmpfs na serwerze, który nie ma dużej ilości ram w momencie wykonywania naprawy MyISAM, albo operacji typu ALTER. Niestety MySQL nie pozwala na definiowania odrębnego katalogu tymczasowego dla tabel tymczasowych oraz dla plików filesort. Nie do wszystkiego się to nadaje. W przypadku małych baz to nie problem, ale różnie to bywa. Więc rozwiązanie na pewno nie jest uniwersalne. Jednak, w żadnym wypadku nie neguje tego, bo istotnie najwydajniej jest wrzucić wszystko tymczasowe w ramdisk.

 

Co do ext2, archaiczny, nie archaiczny. To samo można powiedzieć o tmpfs, jeżeli patrzeć by na wiek filesystemu, ale przecież nie o to chodzi. Nie jest to zły filesystem, a skoro się sprawdza to można go używać. W wolnej chwili muszę sprawdzić jak wypada na tle ext4, z wyłączonym księgowaniem.

Edytowano Luty 12, 2012 przez malu (zobacz historię edycji)

[Gość patrys]

To nie zdrowy rozsądek, a zabijanie wydajności i przeznaczenia /tmp.

Przy stosowaniu tego na dysku twardym, wypadało by to czyścić z przejściem init'a.

Bo nie było by fajnym gdyby zostały jakieś pliki .lock i podobne po restarcie maszyny.

Też pomaga to w optymalizacji, często można przekierować jakiś drobny cache plikowy do /tmp niż bawić się w /dev/shm.

 

Napisałem o tej wielkości ramu, jednak serwery bazodanowe mają go z reguły dużo, choć zawsze możemy dynamicznie zwiększyć /tmp.

Przyniesie to sporą poprawę w działaniu serwera MySQL jeżeli będzie on korzystał z ramu, a nie dysku do przetwarzania danych.

Problemem może być naprawdę jakiś serwer bazodanowy który obsługuje wielkie tabele i ma znikomą ilość ramu.

 

Co do MySQL, to pozwala na definicje katalogu tymczasowego, opcja "--tmpdir".

 

Widziałem sporo zastosowań serwerów i nie wiem naprawdę gdzie jest sens stosowania aktualnie partycji na ext2.

Ext4 jak i kolega XFS dostają kopa przy wyłączonych barierach, jednak tu warto jest mieć BBU

[malu 460]

To nie zdrowy rozsądek, a zabijanie wydajności i przeznaczenia /tmp.

Przy stosowaniu tego na dysku twardym, wypadało by to czyścić z przejściem init'a.

Bo nie było by fajnym gdyby zostały jakieś pliki .lock i podobne po restarcie maszyny.

Też pomaga to w optymalizacji, często można przekierować jakiś drobny cache plikowy do /tmp niż bawić się w /dev/shm.

 

Napisałem o tej wielkości ramu, jednak serwery bazodanowe mają go z reguły dużo, choć zawsze możemy dynamicznie zwiększyć /tmp.

Przyniesie to sporą poprawę w działaniu serwera MySQL jeżeli będzie on korzystał z ramu, a nie dysku do przetwarzania danych.

Problemem może być naprawdę jakiś serwer bazodanowy który obsługuje wielkie tabele i ma znikomą ilość ramu.

 

Co do MySQL, to pozwala na definicje katalogu tymczasowego, opcja "--tmpdir".

 

Widziałem sporo zastosowań serwerów i nie wiem naprawdę gdzie jest sens stosowania aktualnie partycji na ext2.

Ext4 jak i kolega XFS dostają kopa przy wyłączonych barierach, jednak tu warto jest mieć BBU

 

Zdrowy rozsądek miałem na myśli, jako klucz do odpowiedniego wykorzystania tmpfs, bo jak wskazałem nie wszędzie się to sprawdzi i podawanie tego jako złotego środka jest zgoła błędne.

 

Istotnie wraz z startem systemu dobrze by było przeczyścić /tmp. Co do samego zysku wydajnościowego, to jest oczywiste - szczególnie w przypadku złej konfiguracji samego daemona. (W przypadku, gdy dane będzie mu tworzyć tabele tymczasowe na dysku)

 

Co do --tmpdir - przeczytaj jeszcze raz moje zdanie. Pisałem o ustaleniu odrębnych katalogów dla tabel tymczasowych i filesort`ów.

 

Co do zastosowania ext2, istotnie można go zastąpić jakimkolwiek systemem bez journalingu w konkretnym zastosowaniu. Ale skoro filesystem jest stabilny, spełnia pokładane założenia to nie jest błędem jego używanie.

[markopolo 0]

co powiecie na taki rokład partycji

home, /, tmp, swap na SATA 500GB

var na SSD 128GB (bazy danych)

srv na SSD 128GB (pliki skrypty klientów)