Enorme load door bittorrent

Pagina: 1
Acties:

  • eppie
  • Registratie: Maart 2000
  • Niet online
(overleden)
Hallo,

Ik zit met een probleempje met mijn server. Sinds vandaag heb ik er TorrentFlux op geinstalleerd en een stuk of 7 torrents aan het downloaden gezet. Nou heeft deze pc echter een load van 20+ :( :(

6 torrentjes lijken me nou niet zo zwaar om deze load te creeren dus ik met top kijken wie dat wel doet en nou zie ik echter het volgende:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17948 www-data  18   0 57656 7032  804 D  7.8  5.6   2:48.48 python
17699 eppie     16   0  9172 1720  696 D  4.8  1.4   4:09.04 smbd
17986 www-data  18   0 57720 6860  800 D  1.3  5.5   1:54.96 python
17765 www-data  16   0 46244 6016  864 D  0.8  4.8   0:40.65 python
18128 www-data  18   0 44992 7588  788 D  0.6  6.1   0:40.06 python
17786 www-data  17   0 71720 6968  704 D  0.4  5.6   4:01.26 python
18985 mysql     18   0 27448 5188 1808 D  0.4  4.1   0:00.05 mysqld
  117 root      15   0     0    0    0 D  0.2  0.0  14:23.34 kswapd0
17957 www-data  16   0 49524 6440  656 D  0.2  5.1   1:01.26 python
18061 www-data  17   0 48272 6756  764 D  0.2  5.4   0:46.72 python
    1 root      16   0  1584   68   44 S  0.0  0.1   0:02.87 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:05.70 ksoftirqd/0
    3 root      10  -5     0    0    0 S  0.0  0.0   0:00.38 events/0


Helemaal geen hoge load te vinden :(

Wat kan nou die hoge load veroorzaken? Of is een p3-700 mhz gewoon te langzaam voor 6 torrentjes?

Systeem:
Debian 3.1
p3-700
128mb ram

  • Y0ur1
  • Registratie: Oktober 2000
  • Niet online
Volgens mij is dit doodnormaal.

Ik gebruik azureus(java) onder gnome, en met 3 torrents gaat mijn server al over de zeik. Het is een XP2400 met 512mb ram, alles gaat traag als dikke stront.

  • moto-moi
  • Registratie: Juli 2001
  • Laatst online: 09-06-2011

moto-moi

Ja, ik haat jou ook :w

Wat komt er uit een minuutje 'vmstat 5' ? :)

God, root, what is difference? | Talga Vassternich | IBM zuigt


  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 15:05
swapperdeswap... allemaal in D status en je kswapd vreet CPU tijd... zegt mij genoeg: te weinig geheugen.

  • Vyo
  • Registratie: November 2003
  • Niet online

Vyo

Y0ur1 schreef op maandag 05 september 2005 @ 00:32:
Volgens mij is dit doodnormaal.

Ik gebruik azureus(java) onder gnome, en met 3 torrents gaat mijn server al over de zeik. Het is een XP2400 met 512mb ram, alles gaat traag als dikke stront.
Azureus draait toch in een virtual machine? Overigens vind ik het best meevallen, heb zelf een XP2400+ met een 1GB Ram en ik heb vaak 3 torrents die seeden en 2 die downen.

Ik moet zeggen dat ik het vroeger wel echt merkte qua performance, maar sinds ik een sloot ram erbij heb niet meer :)

  • eppie
  • Registratie: Maart 2000
  • Niet online
(overleden)
vmstat 5:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
server:/data/upload/eppie# vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0 15 216696   2060  18696   3536   15   32    39     1    7    21  7  6 65 23
 0 16 216468   2040  18316   2608 1902  210  2342   301 1441   562 25  5  0 70
 1 11 216088   2072  18160   3140 1634  146  2508   283 1581   589 21  6  0 73
 0 20 215096   2028  17560   2780 2232  112  2823   241 1831   689 24  7  0 69
 1 11 216860   2780  17928   3724  934  483  1262   672 1871   521  7  6  0 87
 0 12 216364   2416  17848   3200 1754  130  2266   292 1958   726 14  7  0 79
 0 20 216252   2276  17572   2944 1837  228  2369   369 2068   957 23 10  0 67
 2 23 216840   3464  17100   2700 1324  304  1434   492 1746   760 14  7  0 79
 2 11 215768   2368  16760   2456 2426  125  2533   261 1680   817 16  7  0 77
 0 26 216328   1920  16660   2432 1329  307  1475   361 1516   527 10  4  0 85
 0 23 216344   1888  16656   2692 1608  238  1782   258 1302   405  6  2  0 92

  • eppie
  • Registratie: Maart 2000
  • Niet online
(overleden)
Ik zal er morgen is 128 of meer bij ingooien kijken of dat helpt. iig alvast bedankt voor de snelle reply's

edit:
meminfo
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
server:/data/upload/eppie# cat /proc/meminfo
MemTotal:       125064 kB
MemFree:          3440 kB
Buffers:         14724 kB
Cached:           2816 kB
SwapCached:        764 kB
Active:          56996 kB
Inactive:        47312 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       125064 kB
LowFree:          3440 kB
SwapTotal:      216868 kB
SwapFree:            0 kB
Dirty:              16 kB
Writeback:          60 kB
Mapped:          87308 kB
Slab:            14344 kB
CommitLimit:    279400 kB
Committed_AS:   698496 kB
PageTables:       1248 kB
VmallocTotal:   909236 kB
VmallocUsed:      1388 kB
VmallocChunk:   907836 kB
server:/data/upload/eppie#


Samba gebruikt ook altijd 10-30% cpu volgens top terwijl het dan op dat moment helemaal niet gebruikt word. :(

[ Voor 85% gewijzigd door eppie op 05-09-2005 02:04 ]


  • Arnout
  • Registratie: December 2000
  • Laatst online: 18-03 20:15
Hoge load wordt veroorzaakt door cpu die wacht op i/o (gezien je vmstat uitvoer).

korte uitleg:
bittorrent. Worden direct weer gedeeld terwijl jij aan het downloaden bent.
6 bittorrents aan het downloaden, stel er zitten per torrent 6 andere gebruikers bij jouw te downloaden.

Dan heb je 6*6=36 connecties die iets van je downloaden. De schijf moet dus heel veel heen en weer, vooral als het files van een formaat zijn wat niet gecached kan worden. Een snellere schijf (met name access tijd) zou helpen, of meer geheugen (maar dat laatste betwijfel ik, of het moet heel veel zijn).

[ Voor 3% gewijzigd door Arnout op 05-09-2005 07:47 ]


  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 14-03 12:48

deadinspace

The what goes where now?

Arnout schreef op maandag 05 september 2005 @ 07:46:
Dan heb je 6*6=36 connecties die iets van je downloaden. De schijf moet dus heel veel heen en weer, vooral als het files van een formaat zijn wat niet gecached kan worden. Een snellere schijf (met name access tijd) zou helpen, of meer geheugen (maar dat laatste betwijfel ik, of het moet heel veel zijn).
Hoewel je gelijk hebt dat bittorrent veel seeken veroorzaakt, denk ik dat extra geheugen hier aanzienlijk gaat helpen. Als je goed naar zijn vmstat output kijkt dan zie je dat hij zo'n 200 MB in zijn swap zit, en dat er constant rond de 3 MB/sec ingeswapt wordt, en 1.5MB/sec uitgeswapt. Normale disk I/O is maar 250 KB/sec in en 2 MB/sec out.

Topicstarter: kijk ook eens met top in memory-sort mode (M), en controleer of DMA aanstaat voor je harddisk.

  • Arnout
  • Registratie: December 2000
  • Laatst online: 18-03 20:15
Ok, extra RAM zal inderdaad wel helpen, had niet gezien dat er maar 128 in zat.

  • eppie
  • Registratie: Maart 2000
  • Niet online
(overleden)
Ok ik zal dma checken (meenda dat wel aanstaat en dat ik met de hd wel 15mb/sec haalde minimaal) en extra ram er in totaal 384mb. Top M zal ik na een reboot doen als ik er fatsoenlijk bij kan :P

Wat ik wel raar vind is dat ik TorrentFlux + Bittornado gebruik en dat ik daarvoor alleen bittornado gebruikte (btdownloadcurses) en toen kon ik er wel 6 draaien met een load van +-5 ipv 20.

Edit:

Nou heb ik er 384 mb ram ingezet kijken of dit nu beter gaat. Wel zag ik dat de hd's die op de onboard ide controller zitten wel DMA hebben en de schijven die p een losse controller zitten (cmd648) in pio mode draaien :( volgens DMESG. Nou zet ik ze later met hdparm op X68 wat goed gaat volgens hdparm. Controlleer ik dit echter dan staat die weer op PIO modes :( hoe los ik dit op?

Edit 2:

Heb er nu 384Mb in zitten en download nu met 10 torrents en een load van +-2 dus het heeft zeker geholpen :D

[ Voor 42% gewijzigd door eppie op 05-09-2005 13:10 ]


  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 15:05
CMD64x-achtigen en UDMA gaat eigenlijk nooit goed, heb dit ook gezien met FreeBSD op een sparc met een CMD648. Die chipsets zijn buggy en doen geen betrouwbare DMA. Misschien herinner je je nog een krantenartikel de nodige jaren terug, waarin gepraat werd over de "Killer chip". Deze chip was gewoon de PC-Tech RZ100 (ook een IDE controller) die stiekum data verloor waarbij je het pas merkte op het moment dat het te laat was. De CMD64x-achtigen zijn in principe net zo erg.

  • doelman
  • Registratie: April 2004
  • Laatst online: 05-02 12:23
Je kunt ook gebruik maken van rTorrent als client. Is erg snel, weinig geheugen, minder load...
Alleen command-based. En tsja, als je dat niet durft...

En lees btw ff-tjes de handleiding, als je het prog eenmaal kent, is het zeer makkelijk. Is in 10minuutjes te leren.

[ Voor 29% gewijzigd door doelman op 06-09-2005 00:49 ]

Mijn pianomuziek: http://www.youtube.com/user/doelman

Pagina: 1