Schlagwort-Archive: Linux

Transmission uTP and UDP buffer optimizations

Recently in debug mode on a box running Transmission to seed BackTrack Torrents:

[17:42:40.319] UDP Failed to set receive buffer: requested 4194304, got 262142 (tr-udp.c:75)
[17:42:40.319] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:80)
[17:42:40.319] UDP Failed to set send buffer: requested 1048576, got 262142 (tr-udp.c:86)
[17:42:40.319] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:91)

This message tries to tell us, that for some reason, Transmission would like to have 4 Megabytes of receive buffer and 1 Megabyte send buffer for it’s UDP socket. It turns out that the support for uTP, the uTorrent transport protocol, is implemented using a single socket.

By tuning the two variables, higher throughput can be achieved more easily using uTP.

Here is the relevant part from the changeset:

Since we’re using a single UDP socket to implement multiple uTP sockets,
and since we’re not always timely in servicing an incoming UDP packet,
it’s important to use a large receive buffer. The send buffer is probably
less critical, we increase it nonetheless.

Four Megabyte might seem huge for embedded clients, but running behind a fast dedicated connection, it might even be too small when Transmission has to handle hundreds of connections. I recommend to use 16 Megabyte for receive buffering and 4 for the send buffer. That is, because uTP implements a retransmission algorithm and by scaling up the buffers we achieve less retransmits because of dropped datagrams. Let’s set it up that way.

echo 'net.core.rmem_max = 16777216' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 4194304' >> /etc/sysctl.conf
sysctl -p

Alternativer DNS Server

EDIT: Aktuelle Informationen zum DNS-Server und dessen IP gibt es in diesem Beitrag.

Seit spätestens 2003 betreibe ich meinen DNS Server selbst zuhause. Das bringt mir gerade beim surfen im Internet einen kleinen Geschwindigkeitsvorteil, weil oft aufgerufene Webseiten im Cache bleiben. Durch einen glücklichen Zufall kann ich den Dienst jetzt allgemein zugänglich zur Verfügung stellen.

Die IP-Adresse des DNS Servers lautet:

EDIT: Siehe hier.

DNS ist das Telefonbuch des Internets. Um diesen Blog zu erreichen wurde zum Namen falkhusemann.de die zugehörige (IP-)Nummer bestimmt. Die zuständigen voreingestellten DNS-Server werden meist durch den jeweiligen Internetanbieter betrieben.

Personenbezogene Daten speichert mein DNS Server nicht. Einzig aggregierte Statistiken werden erzeugt und sind für jeden hier einsehbar. Eine Funktionsgarantie für den Dienst kann ich natürlich nicht geben, eine Auswertung der Verfügbarkeit seit Inbetriebnahme aber schon.

Zusätzlich zum Auflösen der ICANN Domains wie .de oder .com ist der Server in das OpenNIC Projekt eingebunden und kann damit eine Menge alternativer TLDs wie .geek oder .null auflösen. OpenNIC ist ein nicht-kommerzielles Projekt, dass alternative DNS Server zur Verfügung stellt.

Eine interaktive Anleitung, wie OpenNIC eingebunden werden kann, ist hier aufrufbar. Der CCC bietet eine allgemein Anleitung für viele Betriebssysteme.

Transmission auto-delete Quota Skript

Möchte man immer die aktuellsten frei zugänglichen Linux-Distributions Torrents herunterladen, um andere Nutzer durch die eigene Bandbreite zu unterstützen, wird irgendwann die Festplatte voll. Dieses Skript schafft Abhilfe.

#!/bin/bash
# transmission-quota.bash
#
# FIFO quota for transmission-daemon.
# This script forces a maximum size upon
# your transmission download directory
# by deleting the oldest torrent, until
# the quota is met again.
#
# Run regularily from cron:
# */5 * * * *     /home/torrent/transmission-quota.bash
#

# Where is your transmission download directory?
TR_DIR="/path/to/your/transmission/downloads"

# How big in bytes may the download directory grow?
TR_MAXBYTES=1879048192000

# Wheres your transmission-remote binary?
CLIPATH="/usr/bin/transmission-remote"

# Login:Password, if applicable
TR_UPASS="myUsername:myPassword"

# URL to Transmission RPC Interface (usually http://X:9091/transmission/rpc)
TR_URL="http://localhost:9091/transmission/rpc"

# # # No Configuration needed below here # # #

while [ "`du -sb ${TR_DIR} | awk '{print $1}'`" -gt "${TR_MAXBYTES}" ]; do
        CURRENT_SEEDING=`${CLIPATH} ${TR_URL} -n ${TR_UPASS} -l | awk '{ if ($2 == "100%") print $1 }' | sed 's/*$//'`
        OLDEST_TIMESTAMP=`date +%s`

        for torrent in ${CURRENT_SEEDING}
        do
                DATE_ADDED=`${CLIPATH} ${TR_URL} -n ${TR_UPASS} -t ${torrent} -i |grep "Date added:" | sed 's/Date added://g'`
                TIMESTAMP_ADDED=`date --date "${DATE_ADDED}" +%s`
                if [ "${TIMESTAMP_ADDED}" -lt "${OLDEST_TIMESTAMP}" ]; then
                        OLDEST_TIMESTAMP=${TIMESTAMP_ADDED}
                        OLDEST_ID=${torrent}
                fi
        done
        ${CLIPATH} ${TR_URL} -n ${TR_UPASS} -t ${OLDEST_ID} --remove-and-delete &> /dev/null
        DAYS_AGO=`echo $(( ( $(date +%s) - $OLDEST_TIMESTAMP ) / 3600 / 24 ))`
        echo deleted torrent id ${OLDEST_ID} from ${DAYS_AGO} days ago | logger -t transmission-quota
done

SNMP mit Munin

Wer im SoHo-Bereich bisher Munin für das Netzwerk Monitoring eingesetzt hat, kann beim neuen Switch oder AccessPoint eine böse Überraschung erleben. Ohne munin-node kein Monitoring. Dabei unterstützt Munin SNMP fähige Geräte sehr elegant; wenn man ein paar Vorraussetzungen beachtet.

SNMP wird in Munin eingebunden, indem ein munin-node die SNMP-Informationen zur Verfügung stellt. Auf dem gewählten Host (bestenfalls ein Linux System), kann Munin die unterstützten Plugins des SNMP fähigen Geräts selbst finden. Hier am Beispiel eines Netgear GS716T (sehr einfacher WebSmart Switch) mit dem Hostnamen coreswitch.

1. Unterstützte Plugins aktivieren

munin-node-configure --snmp coreswitch --snmpversion 2c --snmpcommunity meineROsnmpCOMMUNITY --suggest --shell

Die manpage von munin-node-configure verrät, dass hier auch die SNMP Versionen 1 und 3 unterstützt werden. Der Befehl liefert auf Basis der SNMP MIB des Switches direkt Shellbefehle, die alle unterstützten Interface- und Informations-Plugins in die laufende Munin Konfiguration einbinden. Sehr komfortabel.

2. Neues Gerät in munin.conf eintragen

Hier ist der erste Fallstrick versteckt. Munin erwartet, dass der Node-Name in der Konfigurationsdatei exakt dem Hostnamen entspricht (in diesem Fall coreswitch). Wählt man einen eigenen Namen, kommt es bereits zu Problemen.

[coreswitch]
    address 127.0.0.1
    use_node_name no

3. SNMP Community und Version in /etc/munin/plugin-conf.d/munin-node festlegen

Hier gibt es zu beachten, dass mit dem regulären Ausdruck in eckigen Klammern (hier snmp_coreswitch*), alle Plugins die für den Switch im ersten Schritt aktiviert wurden, abgedeckt sein müssen. Im Zweifelsfall lässt sich das mit ls /etc/munin/plugins/snmp_coreswitch* nocheinmal prüfen.

# added by hand
[snmp_coreswitch*]
env.community meineROsnmpCOMMUNITY
env.version 2

Nach fünf Minuten sind die ersten Graphen des neuen SNMP Geräts erstellt. Weitere Informationen zur SNMP Einbindung in Munin finden sich im Wiki des Projekts.

Wer unbedingt einen anderen Node-Namen in der Datei munin.conf (und damit im Webinterface) benutzen möchte, kann das, indem in der Datei /etc/munin/plugin-conf.d/munin-node unter der SNMP Community mittels env.host die IP-Adresse oder Hostname des SNMP Geräts angegeben wird.

Linux Software-RAID für unternehmenskritische Anwendungen

Inhalt

Motivation

Seit den 80er Jahren (Erstes Paper zu RAID,PDF, Carnegie Mellon University) spielt RAID eine Rolle im Serverbetrieb. In den meisten Fällen wird dabei eine Menge von Festplatten durch eine weitere Abstraktionsebene (den RAID-Adapter) als eine Einheit ins Betriebssystem abgebildet (den RAID-Verbund) . Die selbe Funktion kann aber seit mindestens 13 Jahren (Software-RAID für Linux von Ingo Molnar) auch vom Linux-Kernel bewältigt werden.

In Servern und auch Desktops wird immer öfter über ein RAID nachgedacht und die bestehende Meinung in vielen Foren und Magazinen ist, dass in unternehmenskritischen Systemen Hardware-RAID besser geeignet ist, als Software-RAID. Stimmt das so, oder vollzieht sich eine Wende in diesem Bereich?
Linux Software-RAID für unternehmenskritische Anwendungen weiterlesen