Aus aktuellem Anlass muss ich noch einmal auf
Bandbreite und Latenz herumreiten und vielleicht noch hinzufügen, dass auch die Anzahl der Anfragen durchaus eine Rolle bei Performance-Betrachtungen spielt.
Wir hatten hier auf einem System massive Performance-Probleme und ich habe relativ schnell herausgefunden, dass ein bestimmter User und von diesem ein bestimmter Prozess für einen grossen Teil der Festplattenlast verantwortlich ist.
Der Applikationsbetreuer war der Meinung, dass das nicht sein könne, da der Teil der Applikation kaum bzw. nur sehr wenig schreibt. Das stimmt, er hat wirklich nicht viel geschrieben, aber dafür wenige Bytes und diese sehr häufig. Das hat die IO-Queue gefüllt und weitere Zugriffe blockiert.
Einige Zeit später hat der Betreuer einfach mal den Prozess beendet und siehe da, die Performance der übrigen Komponenten war sehr hoch.
Lehre, die man daraus ziehen sollte: Glaubt keinem Applikationsbetreuer!
Nein, im Ernst: Es ist wichtig, dass man genau weiss, was eine Applikation tut und noch wichtiger ist es, Performance nicht alleine am Durchsatz fest zu machen. Latenz und Anzahl der Requests spielen ebenfalls eine Rolle.
Nach meinen wirklich sehr guten
Erfahrungen mit DigitalOcean, interessiert mich, welche bezahlbaren Cloudprovider Ihr kennt und womit Ihr Erfahrung habt. Mich interessiert vor allem IaaS (Infrastructure as a service).
Für die einzelnen Begrifflichkeiten verweise ich auf
diesen Artikel hier oder den
Cloud-Computing-Artikel in der Wikipedia.
•
Amazon EC2
•
DigitalOcean
•
Google Compute
•
JiffyBox (in Deutschland)
•
Linode
•
Microsoft Azure
•
Rackspace
•
teutoStack (in Deutschland)
Um den
update daemon von Tiny Tiny RSS unter
systemd (
CentOS 7) auch bei einem Serverneustart direkt verfügbar zu haben, habe ich das unten stehende Unitfile geschrieben, vielleicht hilft es auch Euch.
Man kann von systemd halten, was man möchte, ich finde es aber deutlich eleganter als
System V Initskripte.
[Unit]
Description=Tiny Tiny RSS update daemon
After=network.target mariadb.service
Requires=mariadb.service
[Service]
User=apache
Group=apache
WorkingDirectory=/â var/â www/â html/â ttr
Type=simple
StandardOutput=null
StandardError=syslog
ExecStart=/â usr/â bin/â php ./â update_daemon2.php
PrivateTmp=true
InaccessibleDirectories=/â home /â root /â boot /â opt /â mnt /â media
ReadOnlyDirectories=/â etc /â usr
[Install]
WantedBy=multi-â user.target
Einfach nach
/lib/systemd/system/ttrss-update.service kopieren und mittels
systemctl daemon-reload einlesen (den Befehl muss man auch ausführen, wenn man das Skript manuell ändert).
Testen mit
systemctl start ttrss-update
systemctl status ttrss-update
und, wenn alles erfolgreich war mit dem folgenden Befehl aktivieren:
systemctl enable ttrss-update
Von Zeit zu Zeit lohnt es sich
Git-Repositories
neu zu packen oder den Müll weg zu bringen (mittels "garbage collection, der Befehl ist
git gc).
Auch beim Auschecken oder Klonen von grossen Repositories packt Git neu.
Da ich mit den Standard-Einstellungen regelmässig ware Swap-Orgien erlebt habe, lohnt es sich, die Ressourcen für Git zu begrenzen.
In der Standard-Einstellung benutzt Git pro Core und
Hyper-Threading je einen Thread. Da Hyperthreading keinen "echten Prozessor" zur Basis hat, steht aufgrund vieler
Kontextwechsel das System nahezu still. Ein System mit zwei Kernen und Hyperthreading wird von Git mit vier Threads konfiguriert und jedem Thread steht im Standard der komplette Arbeitsspeicher zur Verfügung.
Das ist ein bisschen viel. Und die folgenden Konfigurationsoptionen begrenzen das ein wenig.
git config --global pack.threads 2
git config --global pack.windowMemory 1073741824
git config --global pack.depth 250
git config --global pack.window 250
Die genaue Beschreibung der einzelnen Optionen lassen sich auf der
git-config-Manpage nachlesen.
Das Repack-Skript auf der oben verlinkten Webseite hat sich damit natürlich auch verändert.
#!/bin/bash
case $(uname) in
"Linux")
renice -n 19 -p $$
ionice -c 2 -n 7 -p $$
;;
"SunOS")
renice -n 19 -p $$
;;
esac
start_directory=$PWD
for i in $(find ${start_directory} -name '.git' -type d); do
du -hs ${i}/..
cd ${i}/..
git gc
git repack -a -d
du -hs ${i}/..
echo
done
Dieses Skript ist Teil meines
littlehelpers-Repositories auf GitHub.
Einer der grössten Kritikpunkte an
Tiny Tiny RSS - neben der Tatsache, dass der Hauptentwickler ein Arctrl-wctrl-ww sozial schwierig ist - ist das Aussehen.
Christian Grube hat mich bei Google+ schon vor Monaten auf dieses wirklich hervorragende Theme für Tiny Tiny RSS hingewiesen, ich kann es nur empfehlen:
Das
Feedly-Theme für Tiny Tiny RSS.
Der Screenshot ist aus
diesem Forenthread.