rTorrent: Cannot allocate memory

Vad har du angett för värde för "max_memory_usage"?
Hur många upload-slots har du öppnat?

Prova ange i bytes, förslagsvis 768MB, vilket får anges som
max_memory_usage = 805306368

Varje slot tar runt 2MB, så om du kör många torrents samtidigt blir det en ganska stor minnesåtgång med så många slots/torrent.

Prova ge färre slots, µtorrent har som exempel bara 4 slots som standardvärde.
Och det är ju som sagt till upload, du kommer ju kunna ladda hem snabbt ändå.. (:

EDIT: Vill du ha skön ratio så ska det väl inte spela jättestor roll om du delar till många långsamt eller snabbt till några få?

Helt tvärtom, rTorrent är det bästa du kan ha. Du får veta vad inställningarna betyder bara. Jag har väldigt goda källor på att rTorrent kan seeda 600+ torrents på 100 Mbps-uppkoppling med full belastning utan att ta mer än ~100 MB RAM. I stort sett alla tjänster som erbjuder seedboxes och liknande använder rTorrent pga dess resurssnålhet.

Titta på info för valfri torrent och se vad som står under "Memory usage" och "Max memory usage". Om du observerar detta när du gör olika saker så ser du vad det är som tar emot i ditt fall.

Minnet går speciellt åt om du har många nedladdningar igång samtidigt. För att inte överbelasta diskarna så lagras en viss mängd data (EDIT: efter att ha läst på så är det beroende på chunkstorlek för torrenten, tror inte det är möjligt att ändra) per peer i RAM innan det skrivs till disk. Laddar du ner från 40 peers samtidigt så blir det då snabbt mycket data att lagra i RAM. Öka `max_memory_usage` eller minska/stäng av RAM-cachen (EDIT: som sagt, tror inte längre att man kan ändra just den delen av cachandet. Se senare post i stället) om ditt minne inte räcker till.

RTorrentPerformanceTuning — The libTorrent and rTorrent Project — första punkten.

Minskar du värdena så kommer mindre RAM användas — men din disk kommer få jobba mer med små dataläsningar/skrivningar.

(Bumpar på användarbegäran)

`receive_buffer_size` är inte hela sanningen gällande RAM-cache. Har inte ändrat på detta värde själv, men om det är som du säger gällande hastigheten så kanske det är ett värde man bara ska låta vara. Detta värde kanske inte är så avgörande för RAM-åtgång trots allt.

När man laddar hem så lagrar rTorrent hela den aktuella "chunk"en i RAM innan den skriver till disk. Sitter man på en torrent med 4 MB chunksize så tankar man ner 4 MB till RAM innan det skrivs. Om man har väldigt många simultana anslutningar (många peers med låga hastigheter, vanligen) så sitter alltså rTorrent med kanske flera hundra simultana chunks som den vill hålla i minnet, och det är vanligen då man maxar och rTorrent börjar klaga på att den inte kan allokera minne.

Att rTorrent vill hålla en hel chunk i minnet tror jag är en fundamental design, och inget man kan ändra på. Det skulle också troligen vara förknippat med stora prestandaförluster att inte jobba på det sättet. Vad man däremot kan begränsa är ju antalet simultana anslutningar. Tillåter man bara 50 anslutningar så får man max ungefär 50 chunks*4 MB/chunk = 200 MB minnesåtgång ("chunk size" kan dock variera kraftigt, från 256 kB till 8 MB är vanligt).

Detsamma gäller när en klient vill ladda ner från dig — hela den chunk som de vill ha läses in i RAM-minnets diskcache direkt. Har du 50 uppladdningar igång samtidigt så nås samma siffra.

rTorrents felmeddelande låter värre än vad det är — när man slår i RAM-taket så antar jag att man helt enkelt inte kan allokera chunkutrymme i RAM för fler anslutningar. Om de tillgängliga anslutningarna räcker för att maxa linan så spelar det ingen roll. När man laddat färdigt en chunk så skrivs den till disk och utrymmet frigörs för en ny anslutning. (Datorn brukar sega en del när man når detta tak dock, vilket jag antar är för att man med många anslutningar behöver köra många simultana skrivningar till disk. Har man bara en enda anslutning med maxhastighet i stället så skriver man sekventiellt när en chunk är nere. Problemet med många simultana skrivningar på olika ställen är att hårddisken får hatta fram och tillbaka, vilket ger en märkbar nersaktning. Har man otur blir nersaktningen så stor att man faktiskt laddar hem data snabbare än man kan skriva till disk, vilket ger pile-up i RAM-minnet, vilket effektivt sänker total nedladdningshastighet.)

Så om man inte gillar att se felet — sänk antalet simultana anslutningar eller höj tillgängligt RAM-minne.

I den tråden hittas tyvärr en del människor som inte förstår hur Linux och rTorrent hanterar minne.

Man sätter `max_memory_usage` i rTorrent — detta inkluderar diskcache (den siffran man ser i "Mem"-raden om man kör "free", inte "± buffers". De som svarat i ticketen borde läst http://www.linuxatemyram.com/ innan de kommenterade). Utan diskcache så kommer man ha kontinuerliga skrivningar och läsningar till disken vilket kommer slöa ner systemet ordentligt och troligen slita mer på diskarna (folk brukar säga detta, tror inte det är "vetenskapligt bevisat", men det är troligt). Antagligen skulle också fragmentationen öka.

Applikationen rTorrents minnesåtgång är försvinnande liten. I stort sett allt minne man ser rTorrent allokera är just diskcache, vilket snabbt kan släppas till andra applikationer.

När rTorrent säger att minnet är slut, så är det liksom inte mycket att göra. Man vill hålla alla chunks i minnet innan man skriver (och många andra torrentprogram jobbar också på det sättet — det är det "smarta" sättet), och har man så många chunks att hålla i minnet att minnet inte räcker till för fler: då kan man inte hålla fler chunks i minnet. Man får vänta tills de som är i minnet är färdignedladdade/uppladdade så att plats för nya chunks finns. Många torrentprogram gör detta i det tysta — rTorrent säger "Cannot allocate RAM".

Har man alldeles för låg `max_memory_usage` satt så kan det bli hastighetsproblem om man lyckas fylla minnet med chunks från långsamma källor, men det går lätt att räkna själv och se att det ska mycket till för att det ska hända. I vanliga fall så kommer det rassla på bra.

Som jag nämnde innan så kan man med "för hög" internethastighet och "för långsamma" diskar nå problemet att rTorrent faktiskt vill skriva snabbare till disk än vad den hinner med, pga nedsaktning vid simultana skrivningar. Man kan hindra detta genom att tillåta färre simultana anslutningar så att man inte hamnar i situationen att 20 chunks vill skrivas samtidigt, men det är inte riktigt rTorrents fel att hårddiskarna inte hänger med. Om något så är det en följd av Bittorrentprotokollet i sig iom att man delar upp filer i småbitar. En sekventiell nedladdning skulle inte ha detta problemet. Ett torrentprogram skulle kanske kunna lösa detta genom att bara skicka iväg en skrivning till disk i taget, men det är mest en gissning från någon som inte ens tittat i källkoden för något torrentprogram. Det ska också väldigt mycket till för att man ska nå detta taket i min erfarenhet.

Det gäller RAM, men den allra största delen av det RAM-minne som rTorrent rapporterar att det använder är s k "diskcache". Det är RAM-utrymme som tillåts användas för att hålla chunks i minnet medans de tankas ner/hashcheckas/laddas upp, för att undvika att kontinuerligt behöva läsa från hårddisken.

Alltså: om någon vill ha chunk #354 från en torrent så kommer rTorrent läsa in hela denna chunk i RAM-minnet och sedan servera datan därifrån. Detta gör att man bara skickar ett kommando om läsning till disken per chunk, vilket är bra. Om chunksize är 4 MB så kommer detta då ta 4 MB diskcache-RAM, så att säga. När chunken är uppladdad och klar så frigörs dock detta minne i teorin, dvs om en annan applikation (eller rTorrent själv för den delen) vill allokera 4 MB RAM så kastar Linux ut chunk #354 från minnet och tillhandahåller det utrymmet. Om ingen specifikt vill ha detta utrymme så ligger dock chunk #354 kvar i minnet rent praktiskt, så om någon annan peer ber om den så behöver ingen ny diskläsning göras. Det är ofta detta man menar när man säger att det är dumt att ha RAM-minne som inte utnyttjas; Linux jobbar med att låta filer ligga kvar i RAM, men snabbt kunna kicka ut dem om det skulle behövas.

När man laddar ner en chunk så ber rTorrent om motsvarande plats i RAM-minnet. När chunken sedan är färdig så hash-checkas den, skrivs till disk och frigörs likt ovan. Det är främst i detta steget man kan få problem, vad jag märkt: om man har hög nedladdningshastighet (jag har bara sett det på 100/100), många nedladdande torrents igång och kanske samtidigt har en annan applikation som pratar med hårddisken i fråga så kan man nå situationen att man inte hinner skriva chunks till disk lika snabbt som man laddar ner. Då kommer de icke-skrivna chunksen behöva ligga kvar i RAM-minnet, som inte kan frigöras (då skulle ju de försvinna då de inte finns någon annanstans), och om situationen pågår ett längre tag (att diskskrivningar är långsammare än nedladdning) så kommer RAM-minnet (rättare sagt: `max_memory_size`) oundvikligt fyllas av chunks som inte är skrivna. Då klagar rTorrent och säger att den inte kan allokera mer RAM, utan måste vänta på att en chunk skrivs till disk innan en ny kan börja laddas ner.

Du kan själv inspektera detta beteende genom att titta på "Transfer list" för varje torrent, där alla nedladdande chunks visas. När saker fungerar väl så ska "[Size #]" vara relativt konstant (beror på antalet anslutna peers). Det betyder att chunks skrivs direkt till disk när de är klara. Om du har torrents på fullt blås och testar att stressa disken i fråga på annat håll, så kommer du se att "Size" kommer öka, och att det kommer ligga kvar många färdiga chunks i "Transfer list". När du slutar stressa disken så kommer dessa chunks börja skrivas snabbare och du kommer gå ner mot den tidigare "Size":n igen.

µtorrent/Deluge/någon annan klient kan inte komma runt hårddiskens begränsningar de heller, men de jobbar på ett annat sätt (tror jag, om de inte anammat rTorrents (bättre) sätt. Då µtorrent ska köras på Windows så måste de isf skriva mycket egen kod för att hantera diskcache på egen hand, vilket Linuxkärnan till stor del sköter för rTorrent. I Win7 kan man aktivera diskcache globalt genom enhetshanteraren och kryssa i "Write cache enabled", men vet inte riktigt hur det är implementerat i praktiken.). De väntar tills varje färdig chunk är skriven till disk innan de börjar ladda hem nästa chunk från en viss peer. På så sätt så kommer RAM-"åtgången" inte rusa, men det gör också att hastigheten direkt kommer gå ner när det går långsamt att accessa disken. rTorrent kan i stället använda RAM-minnet som en buffert när disken har annat att göra, vilket gör att rTorrent är mer resurseffektivt och i praktiken snabbare än andra klienter. Det finns en anledning till att alla seedboxes o dyl kör rTorrentlösningar.

Är man tjurig och trots allt inte vill att det ska se ut som att rTorrent fyller ens RAM-minne, trots att det är odelat positivt, så kan man sänka `max_memory_size` och därmed minska mängden RAM som används till diskcache. rTorrent kommer att säga till att det vill allokera mer RAM, men inte kan, när det känner att "hade jag haft mer diskcache nu så hade jag kunnat upprätthålla max nedladdningshastighet, trots att disken är upptagen, men nu får jag vänta tills jag hunnit skriva det jag redan laddat ner". När rTorrent klagar på RAM så säger den alltså egentligen "nu måste jag vara lika ineffektiv som om jag inte använt diskcache ett tag".

Att jobba på detta sättet gör att om strömmen går eller man dödar rTorrent hårt så kommer de chunks som bara finns i minnet att försvinna (i praktiken så hade dessa chunks öht inte hunnit ha laddats ner om man använt en klient med en annan lösning).

Ytterligare en sak att säga: när man skapar en torrent så anger man "chunk size", vilket vanligen läggs mellan 256 kB och 8 MB. Om man har en liten chunk size så måste man läsa/skriva väldigt många fler gånger från/till disk, vilket kan göra att saker blir problematiska då diskar är långsammare på många små operationer jfr m få stora. Det är inget som man som nedladdare kan göra något åt dock, man är i torrentskaparens våld.

Mycket text, men jag tror allt är on topic .