Czy mogę skonfigurować mój system Linux pod kątem bardziej agresywnego buforowania systemu plików?

119

Nie martwię się ani o użycie pamięci RAM (ponieważ mam już dość), ani o utratę danych w przypadku przypadkowego wyłączenia (ponieważ moja moc jest podtrzymywana, system jest niezawodny, a dane nie są krytyczne). Ale dużo przetwarzam pliki i przydałby mi się wzrost wydajności.

Dlatego chciałbym skonfigurować system tak, aby używał więcej pamięci RAM do buforowania odczytu i zapisu systemu plików, aby pobierać pliki agresywnie (np. Z wyprzedzeniem odczytaj cały plik, do którego aplikacja ma dostęp, jeśli plik ma rozsądny rozmiar lub przynajmniej w przeciwnym razie przeczytaj duży fragment) i rzadziej opróżniaj bufory zapisu. Jak to osiągnąć (czy to możliwe)?

Używam systemów plików ext3 i NTFS (często używam NTFS!) Z XUbuntu 11.10 x86.

Ivan
źródło
6
Jeśli masz dużo pamięci RAM, bardzo dbasz o wydajność i nie martwisz się utratą danych, po prostu skopiuj wszystkie dane na dysk RAM i podaj je stamtąd, odrzucając wszystkie aktualizacje po awarii / wyłączeniu. Jeśli to nie zadziała, być może będziesz musiał zakwalifikować się jako „wystarczająca” dla pamięci RAM lub tego, jak krytyczne są dane.
James Youngman
1
@Nils, komputer jest laptopem, więc uważam, że kontroler jest dość zwyczajny.
Ivan
1
Jednym ze sposobów na znaczną poprawę wydajności jest pominięcie trwałości danych. Po prostu wyłącz synchronizację z dyskiem, nawet jeśli niektóre aplikacje wymagają synchronizacji. Spowoduje to utratę danych, jeśli urządzenie pamięci masowej kiedykolwiek straci energię elektryczną. Jeśli mimo to chcesz to zrobić, po prostu uruchom sudo mount -o ro,nobarrier /path/to/mountpointlub dostosuj, /etc/fstababy uwzględnić nobarriersystem plików, który chcesz poświęcić w celu poprawy wydajności. Jeśli jednak urządzenie pamięci ma wewnętrzną baterię, taką jak seria Intel 320 SSD, korzystanie z niego nobarriernie powoduje utraty danych.
Mikko Rantalainen,
1
Użycie nobarriera nie jest już zalecane w Red Hat Enterprise Linux 6, ponieważ negatywny wpływ barier zapisu na wydajność jest znikomy (około 3%). Korzyści wynikające z barier zapisu zwykle przewyższają korzyści wynikające z wyłączenia ich. Ponadto opcja nobarrier nigdy nie powinna być używana w przypadku pamięci skonfigurowanej na maszynach wirtualnych. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov
1
Dwa punkty - 1) Istnieją dystrybucje linuksowe oparte na Debianie lub Ubuntu, takie jak Puppy Linux i AntiX Linux, i wiele innych, które umieszczają cały system operacyjny w warstwowych partycjach ramdysku (tj. AUFS lub nakładki) i zarządzają nim w przejrzysty sposób. Bardzo szybki! - 2) Odkryliśmy w prawdziwym świecie bardzo duży system, który rzucając w niego więcej pamięci podręcznej może ZMNIEJSZYĆ WYDAJNOŚĆ. Wraz ze wzrostem prędkości przechowywania (tj. SSD) zmniejsza się optymalny rozmiar potrzebnej pamięci podręcznej. Nie ma jednak sposobu, aby dowiedzieć się, jaki jest ten rozmiar bez eksperymentów na danym systemie. Jeśli wzrost nie działa, spróbuj go zmniejszyć.
DocSalvager,

Odpowiedzi:

107

Ogólnie rzecz biorąc, poprawa wydajności pamięci podręcznej dysku jest czymś więcej niż tylko zwiększeniem wielkości pamięci podręcznej systemu plików, chyba że cały system mieści się w pamięci RAM. W takim przypadku należy użyć napędu RAM ( tmpfsjest to dobre, ponieważ w niektórych przypadkach umożliwia powrót do dysku) do przechowywania w środowisku wykonawczym (i być może skrypt initrd do kopiowania systemu z pamięci na dysk RAM podczas uruchamiania).

Nie wiesz, czy twoim urządzeniem pamięci jest dysk SSD czy HDD. Oto, co dla mnie działa (w moim przypadku sdajest to dysk twardy zamontowany w, /homea sdbdysk SSD zamontowany w /).

Najpierw zoptymalizuj część load-stuff-from-storage-to-cache:

Oto moja konfiguracja dysku twardego (upewnij się, że AHCI + NCQ jest włączony w systemie BIOS, jeśli masz przełączniki):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Warto zauważyć, że przypadek dysku twardego jest wysoki fifo_expire_async(zwykle zapis) i długi, slice_syncaby umożliwić pojedynczemu procesowi uzyskanie wysokiej przepustowości (ustaw slice_syncniższą liczbę, jeśli trafisz na sytuacje, w których wiele procesów czeka równolegle na niektóre dane z dysku). Jest slice_idleto zawsze kompromis w przypadku dysków twardych, ale ustawienie go gdzieś w zakresie 3-20 powinno być w porządku, w zależności od użycia dysku i oprogramowania układowego dysku. Wolę celować na niskie wartości, ale ustawienie go zbyt nisko zniszczy Twoją przepustowość. To quantumustawienie wydaje się mieć duży wpływ na przepustowość, ale staraj się utrzymywać ją na jak najniższym poziomie, aby utrzymać opóźnienie na rozsądnym poziomie. Ustawienie quantumzbyt niskiej wartości zniszczy przepustowość. Wartości w zakresie 3-8 wydają się dobrze współpracować z dyskami twardymi. Najgorsze opóźnienie dla odczytu to ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms, jeśli poprawnie zrozumiałem zachowanie jądra. Asynchronizacja jest najczęściej używana przez zapisy, a ponieważ chcesz opóźnić zapis na dysk, ustaw zarówno slice_async_rqi slice_asyncbardzo niskie liczby. Jednak ustawienie slice_async_rqzbyt niskiej wartości może opóźnić odczyty, ponieważ zapisy nie mogą być dłużej opóźniane po odczytach. Mój config spróbuje zapisać danych na dysku co najwyżej po 10 sekundach po dane zostały przekazane do jądra, ale ponieważ można tolerować utratę danych dotyczących strat mocy również zestaw fifo_expire_asyncdo 3600000powiedzieć, że 1 godzina jest w porządku za opóźnienie na dysku. Po prostu utrzymuj slice_asyncniski poziom, ponieważ w przeciwnym razie możesz uzyskać duże opóźnienie odczytu.

hdparmKomenda jest wymagane, aby zapobiec AAM od zabijania wiele spektaklu, który pozwala AHCI + NCQ. Jeśli dysk robi zbyt dużo hałasu, pomiń to.

Oto moja konfiguracja dysku SSD (seria Intel 320):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Tutaj warto zauważyć niskie wartości dla różnych ustawień wycinków. Najważniejszym ustawieniem dla dysku SSD jest to, slice_idlektóre musi być ustawione na 0-1. Ustawienie go na zero przenosi wszystkie decyzje dotyczące porządkowania do natywnego NCQ, a ustawienie go na 1 pozwala jądru na porządkowanie żądań (ale jeśli NCQ jest aktywne, sprzęt może częściowo zastąpić porządkowanie jądra). Przetestuj obie wartości, aby zobaczyć, czy widzisz różnicę. Intel serii 320, wydaje się, że ustawienie slide_idledo 0daje najlepszą wydajność, ale ustawienie go 1daje najlepszą (najniższy) ogólną latencję.

Aby uzyskać więcej informacji o tych tunach, zobacz http://www.linux-mag.com/id/7572/ .

Teraz, gdy skonfigurowaliśmy jądro do ładowania rzeczy z dysku do pamięci podręcznej z rozsądną wydajnością, nadszedł czas, aby dostosować zachowanie pamięci podręcznej:

Według przeprowadzonych przeze mnie testów nie zawracałbym sobie głowy ustawieniem odczytu blockdev. Domyślne ustawienia jądra są w porządku.

Ustaw system tak, aby wolał zamieniać dane pliku niż kod aplikacji (nie ma to znaczenia, jeśli masz wystarczającą ilość pamięci RAM, aby utrzymać cały system plików i cały kod aplikacji oraz całą pamięć wirtualną przydzieloną przez aplikacje w pamięci RAM). Zmniejsza to opóźnienie przełączania między różnymi aplikacjami w porównaniu z opóźnieniem dostępu do dużych plików z jednej aplikacji:

echo 15 > /proc/sys/vm/swappiness

Jeśli wolisz przechowywać aplikacje prawie zawsze w pamięci RAM, możesz ustawić to na 1. Jeśli ustawisz to na zero, jądro nie będzie w ogóle zamieniać, chyba że jest to absolutnie konieczne dla uniknięcia OOM. Jeśli masz ograniczoną pamięć i pracujesz z dużymi plikami (np. Edycja wideo HD), warto ustawić tę wartość na 100.

Ja obecnie (2017) wolę w ogóle nie zamieniać, jeśli masz wystarczającą ilość pamięci RAM. Brak wymiany zwykle powoduje utratę 200-1000 MB pamięci RAM na długo działającym komputerze stacjonarnym. Jestem gotów poświęcić tyle, aby uniknąć opóźnień w najgorszym przypadku (zamiana kodu aplikacji, gdy pamięć RAM jest pełna). W praktyce oznacza to, że wolę OOM Killera niż zamianę. Jeśli zezwolisz / potrzebujesz zamiany, możesz też chcieć zwiększyć /proc/sys/vm/watermark_scale_factor, aby uniknąć opóźnień. Sugerowałbym wartości od 100 do 500. Możesz rozważyć to ustawienie jako zamianę wykorzystania procesora na mniejsze opóźnienia wymiany. Domyślnie jest to 10, a maksymalna możliwa to 1000. Wyższa wartość powinna (zgodnie z dokumentacją jądra ) skutkować większym zużyciem procesora dla kswapdprocesów i niższym całkowitym opóźnieniem zamiany.

Następnie powiedz jądru, aby wolało utrzymywać hierarchię katalogów w pamięci nad zawartością pliku na wypadek, gdyby część pamięci RAM musiała zostać zwolniona (ponownie, jeśli wszystko mieści się w pamięci RAM, to ustawienie nic nie robi):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Oprawa vfs_cache_pressurezbyt niska wartość ma sens, ponieważ w większości przypadków jądro musi znać strukturę katalogów, zanim będzie mogło użyć zawartości pliku z pamięci podręcznej, a zbyt szybkie opróżnienie pamięci podręcznej katalogu sprawi, że pamięć podręczna plików będzie prawie bezwartościowa. Zastanów się nad przejściem do 1 z tym ustawieniem, jeśli masz dużo małych plików (mój system ma około 150 000 zdjęć o rozdzielczości 10 megapikseli i liczy się jako system „dużo małych plików”). Nigdy nie ustawiaj go na zero lub struktura katalogów jest zawsze przechowywana w pamięci, nawet jeśli w systemie kończy się pamięć. Ustawienie tej dużej wartości jest sensowne tylko wtedy, gdy masz tylko kilka dużych plików, które są ciągle odczytywane ponownie (ponownie, przykładowo, edycja wideo HD bez wystarczającej ilości pamięci RAM). Oficjalna dokumentacja jądra mówi, że „

Wyjątek: jeśli masz naprawdę ogromną liczbę plików i katalogów i rzadko dotykasz / odczytujesz / wyświetlasz listę, wszystkie pliki vfs_cache_pressurepowyżej 100 mogą być mądre. Dotyczy to tylko sytuacji, gdy nie masz wystarczającej ilości pamięci RAM i nie możesz utrzymać całej struktury katalogów w pamięci RAM, a nadal masz wystarczającą ilość pamięci RAM do normalnej pamięci podręcznej plików i procesów (np. Serwer plików dla całej firmy z dużą ilością zawartości archiwalnej). Jeśli uważasz, że musisz zwiększyć vfs_cache_pressurepowyżej 100, biegniesz bez wystarczającej ilości pamięci RAM. Zwiększenie vfs_cache_pressuremoże pomóc, ale jedynym prawdziwym rozwiązaniem jest uzyskanie większej ilości pamięci RAM. Po vfs_cache_pressureustawiony na dużą liczbę poświęca średnią wydajność na posiadanie więcej stabilną wydajność ogólna (czyli można uniknąć naprawdę złe zachowanie najgorszy przypadek, ale mamy do czynienia z gorszą ogólną wydajność).

Na koniec powiedz jądru, aby używało do 99% pamięci RAM jako pamięci podręcznej dla zapisów i poinstruuj jądro, aby używało do 50% pamięci RAM przed spowolnieniem procesu pisania (domyślnie dirty_background_ratiojest to 10). Ostrzeżenie: osobiście nie zrobiłbym tego, ale twierdziłeś, że masz wystarczającą ilość pamięci RAM i jesteś gotów stracić dane.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

I powiedz, że opóźnienie zapisu 1h jest w porządku, aby nawet zacząć zapisywać rzeczy na dysku (ponownie, nie zrobiłbym tego):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Jeśli umieścisz je wszystkie /etc/rc.locali na końcu dołączasz, wszystko będzie w pamięci podręcznej jak najszybciej po starcie (zrób to tylko, jeśli twój system plików naprawdę pasuje do pamięci RAM):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Lub nieco prostsza alternatywa, która może działać lepiej (pamięć tylko /homei /usrwyłącznie to zrobić jeśli /homei /usrnaprawdę zmieścić się w pamięci RAM):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&
Mikko Rantalainen
źródło
3
Dobrze poinformowana i ogólnie znacznie lepsza odpowiedź niż zaakceptowana! Ten jest niedoceniany ... Myślę, że większość ludzi chce tylko prostych instrukcji, nie zawracając sobie
głowy
2
@Phpdevpad: Ponadto pytanie brzmiało: „Nie martwię się o użycie pamięci RAM [...]” - nie sądzę, aby jakiekolwiek urządzenie Maemo się kwalifikowało.
Mikko Rantalainen
1
Czy noop lub termin nie jest lepszym harmonogramem dla dysków SSD?
rep_movsd
1
@rep_movsd Używam tylko dysków Intel SSD, ale przynajmniej te dyski są wystarczająco wolne, aby uzyskać lepszą ogólną wydajność dzięki bardziej inteligentnym programom planującym, takim jak CFQ. Sądzę, że jeśli twój dysk SSD poradzi sobie z ponad 100 000 losowymi operacjami IOPS, użycie noop lub terminu byłoby sensowne nawet w przypadku szybkiego procesora. Przez „szybki procesor” mam na myśli coś, co najmniej kilka rdzeni 3GHz jest dostępnych tylko dla IO.
Mikko Rantalainen,
1
Możesz także poczytać o tych tunelach vm z dokumentacji jądra vm .
joeytwiddle
16

Po pierwsze, NIE zalecam dalszego korzystania z NTFS, ponieważ implementacja NTFS w Linuksie będzie w dowolnym momencie powodowała problemy z wydajnością i bezpieczeństwem.

Istnieje kilka rzeczy, które możesz zrobić:

  • użyj niektórych nowszych fs, takich jak ext4lubbtrfs
  • na przykład spróbuj zmienić harmonogram bfq
  • wyłącz zamianę
  • użyj jakiegoś automatycznego programu do wstępnego ładowania preload
  • użyj czegoś takiego jak systemdwstępne ładowanie podczas uruchamiania
  • ... i coś więcej

Może chcesz spróbować :-)

Felix Yan
źródło
1
Już raz całkowicie zrezygnowałem z NTFS na ext4, pozostawiając jedyną partycję NTFS jako partycję systemową Windows. Ale okazało się to dla mnie wiele niedogodności i wróciłem do NTFS jako głównej partycji danych (gdzie przechowuję wszystkie moje dokumenty, pliki do pobrania, projekty, kod źródłowy itp.). Nie rezygnuję z przemyślenia struktury partycji i przepływu pracy (aby użyć mniejszej ilości systemu Windows), ale teraz rezygnacja z NTFS nie wydaje się realistyczną opcją.
Ivan
Jeśli musisz również korzystać z danych w systemie Windows, NTFS może być jedyną opcją. (wiele innych opcji dostępnych, jeśli możesz używać systemu Windows jako maszyny wirtualnej w systemie Linux)
Felix Yan
1
Przydatne byłoby podsumowanie tych rzekomych problemów z NTFS.
underscore_d
2
NTFS w systemie Linux jest praktycznie akceptowalny, z wyjątkiem wydajności. Biorąc pod uwagę, że pytanie dotyczyło konkretnie poprawy wydajności systemu plików, NTFS powinien być pierwszą rzeczą.
Mikko Rantalainen,
Mimo, że btrfsjest to ostatnio zaprojektowany system plików, unikałbym tego, gdyby wymagana była wydajność. Mamy już działa inaczej identycznych systemów z btrfsi ext4systemów plików i ext4wygrywa w realnym świecie z dużym marginesem ( btrfszdaje się wymagać około 4x czasu procesora na ext4potrzeby dla tego samego poziomu wydajności i powoduje więcej operacji dyskowych za pomocą jednego polecenia logicznego). W zależności od obciążenia, sugerowałbym ext4, jfslub xfsdla każdej pracy wymagającej wydajności.
Mikko Rantalainen
8

Czytaj dalej:

W systemach 32-bitowych:

blockdev --setra 8388607 /dev/sda

W systemach 64-bitowych:

blockdev --setra 4294967295 /dev/sda

Napisz za cache:

echo 100 > /proc/sys/vm/dirty_ratio

Spowoduje to wykorzystanie do 100% wolnej pamięci jako pamięci podręcznej zapisu.

Lub możesz wyjść na całość i użyć tmpfs. Jest to istotne tylko, jeśli masz wystarczającą ilość pamięci RAM. Włóż to /etc/fstab. Zamień 100G na ilość fizycznej pamięci RAM.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Następnie:

mkdir /mnt/tmpfs; mount -a

Następnie użyj / mnt / tmpfs.

Ole Tange
źródło
5
Dysk twardy o pojemności 3 GB lub 2 TB? naprawdę? Czy w ogóle wiesz, co robią te opcje?
Cobra_Fast
1
@Cobra_Fast Czy wiesz co to znaczy? Naprawdę nie mam pojęcia i jestem teraz zainteresowany.
syss
3
@syss ustawienia głowicy zapisywane są jako liczba „bloków” pamięci, a nie bajtów lub bitów. Rozmiar jednego bloku jest określany w czasie kompilacji jądra (ponieważ bloki readahead są blokami pamięci) lub czasem tworzenia systemu plików w niektórych przypadkach. Zwykle jednak 1 blok zawiera 512 lub 4096 bajtów. Zobacz linux.die.net/man/8/blockdev
Cobra_Fast
6

Możesz ustawić rozmiar odczytu z wyprzedzeniem blockdev --setra sectors /dev/sda1, gdzie sektory to żądany rozmiar w sektorach 512-bajtowych.

psusi
źródło
2

Moje ustawienie zabójcy jest bardzo proste i bardzo skuteczne:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Wyjaśnienie z dokumentacji jądra :

vfs_cache_pressure

Kontroluje tendencję jądra do odzyskiwania pamięci używanej do buforowania obiektów katalogów i i-węzłów.

Przy domyślnej wartości vfs_cache_pressure = 100 jądro będzie próbowało odzyskać dentries i i-węzły z „uczciwą” szybkością w odniesieniu do odzyskiwania pagecache i swapcache. Zmniejszenie vfs_cache_pressure powoduje, że jądro woli zachować pamięć podręczną dentysty i i-węzła. Gdy vfs_cache_pressure = 0, jądro nigdy nie odzyska dentrali i i-węzłów z powodu presji pamięci i może to łatwo doprowadzić do stanu braku pamięci. Zwiększenie vfs_cache_pressure powyżej 100 powoduje, że jądro woli odzyskać dentries i i-węzły.

vfs_cache_pressure w 2000 roku powoduje, że większość obliczeń odbywa się w pamięci RAM i bardzo późne zapisywanie na dysku.

slm
źródło
4
Ustawienie vfs_cache_pressurezbyt wysokiego (uważam za 2000zbyt wysokie) spowoduje niepotrzebny dostęp do dysku nawet dla prostych rzeczy, takich jak listy katalogów, które powinny łatwo zmieścić się w pamięci podręcznej. Ile masz pamięci RAM i co robisz z systemem? Jak napisałem w odpowiedzi, użycie wysokiej wartości dla tego ustawienia ma sens np. Przy edycji wideo HD z ograniczoną pamięcią RAM.
Mikko Rantalainen,
2
Zauważ, że dokumentacja, o której mowa, kontynuuje: „ Zwiększenie vfs_cache_pressure znacznie powyżej 100 może mieć negatywny wpływ na wydajność. Kod odzyskiwania wymaga różnych blokad w celu znalezienia wolnych katalogów i obiektów i-węzłów. Przy vfs_cache_pressure = 1000 będzie szukał dziesięciokrotnie więcej wolnych obiektów niż tam są ”.
Mikko Rantalainen
1

Nie związane z buforowaniem zapisu, ale związane z zapisami:

  • W przypadku systemu ext4 można całkowicie wyłączyć rejestrowanie

    Zmniejszy to liczbę zapisów na dysku dla poszczególnych aktualizacji, ale może spowodować, że system plików będzie niespójny po nieoczekiwanym zamknięciu, wymagając fsck lub gorzej.

Aby zatrzymać odczytywanie dysku z wyzwalaczy zapisów dysku:

  • Montuj z opcją relatime lub noatime

    Podczas odczytywania pliku metadane „ostatniego dostępu” dla tego pliku są zwykle aktualizowane. Ta noatimeopcja wyłączy to zachowanie. Zmniejsza to niepotrzebne zapisy na dysku, ale nie będziesz już mieć tych metadanych. Niektóre dystrybucje (np. Manjaro) przyjęły to ustawienie domyślne na wszystkich partycjach (prawdopodobnie w celu zwiększenia żywotności wcześniejszych dysków SSD).

    relatimerzadziej aktualizuje czas dostępu, zgodnie z heurystykami, które pomagają w obsłudze aplikacji korzystających z tego czasu. Jest to ustawienie domyślne w systemie Red Hat Enterprise Linux.

Inne opcje:

  • W powyższych komentarzach Mikko podzielił się możliwością montażu z opcją nobarrier . Ale Ivailo zacytował RedHata, który ostrzega przed tym. Jak bardzo chcesz tych dodatkowych 3%?
joeytwiddle
źródło