From rzm w icm.edu.pl  Mon Sep  5 17:49:48 2022
From: rzm w icm.edu.pl (Rafal Maszkowski)
Date: Mon, 5 Sep 2022 17:49:48 +0200
Subject: [Uzytkownicy] =?iso-8859-2?q?nowo=B6ci_sunsite=27owe_od_listopad?=
 =?iso-8859-2?q?a_2021_r=2E?=
In-Reply-To: <20211121165334.GN23501@ukwial.icm.edu.pl>
References: <20130627142705.GA18135@ukwial.icm.edu.pl>
 <20140129202622.GA9053@ukwial.icm.edu.pl>
 <20140314094841.GA31429@ukwial.icm.edu.pl>
 <20141223124259.GA2967@ukwial.icm.edu.pl>
 <20150219234818.GA12070@ukwial.icm.edu.pl>
 <20150611161054.GA8485@ukwial.icm.edu.pl>
 <20170525170915.GA20697@ukwial.icm.edu.pl>
 <20181123135410.pnuf7bq3rgcekaq6@ukwial.icm.edu.pl>
 <20211121165334.GN23501@ukwial.icm.edu.pl>
Message-ID: <20220905154948.GZ2476@ukwial.icm.edu.pl>

Serwis {ftp,http,https,rsync,gopher}://ftp.icm.edu.pl/ zawiera ok. 570
pakietów z 44 mln plików (68 mln razem z katalogami) o całkowitej
objętości 157 TB (w tym 15 TB to zlinkowane duplikaty).

Od listopada nie działo się wiele poza paroma przypadkami spadku
wydajności. Powodów bywało kilka:
- spowolnienie dysków z demobilu
  Pisałem już o tym poprzednio. W backendzie używam m.in. starych (~60
  kh) dysków 6 tB (przez tB oznaczam 1000⁴ B) z demobilu, z których
  połowa w ogóle nie nadaje się do użytku, a niektóre wykazują dziwne
  błędy - przed śmiercią działają nadal, ale powoli, co oczywiście
  spowalnia całą partycję ZFS i nieoczywiście spowalnia również drugą
  partycję ZFS. Zdarzyło się tak kilka razy w okresie sprawozdawczym.
  Wypracowałem metodologię szukania winowajcy - iostat -x 1 5; zpool
  iostat -wv 120 3 - i zmagałem się z problemem już kilka razy.
  Frontend używa dysków, z których większość w ciągu najbliższego
  tygodnia osiągnie równe 100 tys. h, ale są to bardzo trwałe dyski o
  pojemności 1 tB, których poza tym mam spory zapas. Litr spirytusu do
  czyszczenia na 100000 godzin dysków sunsite'a!
- zapchanie partycji ZFS
  Przyzwyczaiwszy się do problemów ze starymi dyskami próbowałem kolejny
  raz wyszukać powyższą metodą winowajcę spowolnienia, aż przypomniałem
  sobie, że ZFS nie lubi totalnego zapchania. Przeniesienie jednego
  pakietu pomogło.
- atak DDoS
  Jeszcze niedawno z sunsite'a wysysano średnio 300 Mbps, potem 600
  Mbps, a ostatnio średnia zaczęła sięgać 1 Gbps. Można by się cieszyć
  zaspokajaniem zapotrzebowania ludności, ale na początku sierpnia
  okazało się, że ostatnie 400 Mbps to zapotrzebowanie Chińskiej
  Republiki Ludowej na jeden jedyny plik. Kiedy zwiększyłem liczbę
  apache'y, dosięgnęło 4000 połączeń z ok. 1000 maszyn. W sumie na razie
  naliczyłem 25 tys. adresów, które sukcesywnie, półautomatycznie
  trafiają do filtra. Czy Republika Chińska mogłaby coś zrobić ze
  zbuntowanymi prowincjami?

Nowe pakiety:
2022: twolame

Poprawki mirrorowania:
2021: [nic]
2022: e1000 fetchmail freeciv gimp ghostbsd ImageMagick linux-manjaro linux-scientificlinux mrtg net-snmp nmap OpenBSD swig

Awarie:
- 2021-09-27…2022-05-22 nie bylo FTP/IPv6 (zauwazyl: PM)
- 2021-12-31 21:22-02:45 awaria zasilania
- 2022-01-03…04,15…22 problemy z NFS-em; 01-28 jednak nie z NFS-em, tylko ponownie z powolnym dyskiem w jednej z partycji ZFS-a
- 2022-03-06 09:40-14:40 awaria backendu
- 2022-08-04 problemy z backendem, od 08-05 do 08-07 czesc pakietow byla niedostepna

Informacje o nowościach pojawiają się w:
- ftp://ftp.icm.edu.pl/.ftp.banner http://ftp.icm.edu.pl/.ftp.banner
  archiwalne są w ftp://ftp.icm.edu.pl/.arch/.ftp.banner.* ,
- czasem w grupie Usenet News pl.internet.komunikaty (awarie i planowane prace),
- na tej liście (jak nie zapomnę).

R.
-- 
„Walczy on z całym zapamiętaniem przeciwko intelektowi” - z akt personalnych prof. A. Baeumlera