| View previous topic :: View next topic |
| Author |
Message |
dirtyboy
neophyte
Joined: 15 Jan 2007
Posts: 8
|
 Posted: Mon Feb 05, 2007 1:26 am Post subject: |
 |
|
| fabtar wrote: | @dirtyboy
P.s: Just for curiosity.
Can anyone(with the CPU/BT problem) here try to disable GeoIP database(remove the link from webinfos and delete the GeopIp file from .mldonkey directory ) and try again with BT... does this "Mambo Jambo" help reducing the load ? |
I'm not sure what you mean by mambo jambo  ...but whatever. 
I did rm * in the web_info folder and the symptoms still persist. I looked in a few config files but I couldn't figure out how to "officially" disable geoip.... so I don't know if that's a problem or not. Wait... is this the option?
ip_blocking_countries_block = true
???
_________________
Slackware 11.0 Kernel 2.6.19.1
Dual CPU P3 1.4GHz Tualatin Core
Tyan Tiger 230T S2507T
1 GB SDRAM
mLdonkey 2.8.2 |
|
| Back to top |
|
 |
fabtar
Sage
Joined: 04 Feb 2004
Posts: 1575
Location: Italy
|
| Posted: Mon Feb 05, 2007 8:52 am Post subject: |
|
|
No, the only way to disable geoip is to remove his "Webinfo" from Ini (so he cannot download the database, and delete the already downlaoded GeoIp.dat database located somewhere in the .mldonkey config directory... I think mldonkey/webinfos , I'm not sure.
I have verified that without this dataabse mldonkey start with eoip disablled.
In fact there is no option to do this.
Te option which you have pointed has another purpose. |
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Mon Feb 05, 2007 11:12 am Post subject: |
|
|
| spiralvoice wrote: | Now I cleaned option ip_blocking_countries, tomorrow I will
check if this had an impact on the system. |
Impact zero.
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Sun Apr 01, 2007 10:39 pm Post subject: |
|
|
| spiralvoice wrote: | Now I cleaned option ip_blocking_countries, tomorrow I will
check if this had an impact on the system. |
It had no impact. I doubt that using geoip database causes high CPU usage.
I am using MLDonkey with the new country stats for some time now, without
higher CPU usage. These stats cause much more accesses to the geoip db,
but it does no harm to the CPU usage.
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
fabtar
Sage
Joined: 04 Feb 2004
Posts: 1575
Location: Italy
|
| Posted: Mon Apr 02, 2007 7:14 am Post subject: |
|
|
| Just for curiosity, have you tried the geoip impact by doing BT downloads too? ( ed2k+bt both meanwhile). |
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Mon Apr 02, 2007 10:19 am Post subject: |
|
|
| fabtar wrote: | | Just for curiosity, have you tried the geoip impact by doing BT downloads too? ( ed2k+bt both meanwhile). |
Did that right now, downloaded Knoppix CD, 700MB in 1,5h, along with
three other BT and 30 EDK files, the three BT ones are still downloading
at 30 kb/s each.
CPU usage increased from 20% to 60%, because number of parallel
connections rose from 50 to 300 on my 300 MHz AMD K6.
Nothing weird happened, MLDonkey is still accessible...
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
lugdunum
neophyte
Joined: 18 Nov 2003
Posts: 38
Location: france
|
| Posted: Wed Apr 04, 2007 6:56 pm Post subject: |
|
|
Hi
I noticed this slowdown too, 2.8.3 and 2.8.4 have problems.
Doing a strace on mlnet, I noticed :
# egrep read STRACE.2.8.2|wc -l; egrep write STRACE.2.8.2|wc -l
216075
125530
# egrep read STRACE.2.8.4|wc -l; egrep write STRACE.2.8.4|wc -l
1022366
84954
so mlnet-2.8.3/2.8.4 is constantly doing read() syscalls and huge memory allocations
| Code: |
19:40:33.243977 _llseek(55, 12677120, [12677120], SEEK_SET) = 0
19:40:33.244034 read(55, "\307y\223]5\265\374\222\v\371\10S\351d\0226w\305P7\252"..., 16384) = 16384
19:40:33.244137 read(55, "\26\271\211\212V\23h]\335ak\254u\260\323j%\231!\247u\241"..., 16384) = 16384
19:40:33.244229 read(55, "\2144\334\266\372\22\365S\257\313uK\354\363\t% 5\37^\32"..., 16384) = 16384
19:40:33.244332 read(55, "\"CV\235Xc8\206}\363\02597\202\302\336\236\215\253\'}\222"..., 16384) = 16384
19:40:33.244423 read(55, "Q\34\332\213OTnK\34\256\265\37\236\272\0319\257%<\302\25"..., 16384) = 16384
19:40:33.244517 read(55, "F\263h\354\31SFD`\34I\310\203v\374j\230\31_t/b\374\256"..., 16384) = 16384
19:40:33.244608 read(55, "\3\0l8\207|\231E\257\243\21 \277h\347_\362\312\261cR[\27"..., 16384) = 16384
19:40:33.244703 read(55, "\202\263\321\225\211\360G\22X\f,: 3\246Ah\16\371\234`\25"..., 16384) = 16384
19:40:33.244793 read(55, "\332\200:\3\315\27\342Dy\355\365c\2178\214\2{\274 \364"..., 16384) = 16384
19:40:33.244884 read(55, "\323<T\331\245\7W\207\260\265\334\246\335w\vX\246\233\33"..., 16384) = 16384
19:40:33.244976 read(55, "\23\v\252Y\204\266\253\230M\234\3058\200\322\236N\256\256"..., 16384) = 16384
19:40:33.245066 read(55, "?n\341\271\0\323\36\366\"\263I\6Gz\"\26\306\224\247\5\325"..., 4096) = 4096
19:40:33.794044 _llseek(55, 12677120, [12677120], SEEK_SET) = 0
19:40:33.794098 read(55, "\307y\223]5\265\374\222\v\371\10S\351d\0226w\305P7\252"..., 16384) = 16384
19:40:33.794212 read(55, "\26\271\211\212V\23h]\335ak\254u\260\323j%\231!\247u\241"..., 16384) = 16384
19:40:33.794328 read(55, "\2144\334\266\372\22\365S\257\313uK\354\363\t% 5\37^\32"..., 16384) = 16384
19:40:33.794431 read(55, "\"CV\235Xc8\206}\363\02597\202\302\336\236\215\253\'}\222"..., 16384) = 16384
19:40:33.794534 read(55, "Q\34\332\213OTnK\34\256\265\37\236\272\0319\257%<\302\25"..., 16384) = 16384
19:40:33.794638 read(55, "F\263h\354\31SFD`\34I\310\203v\374j\230\31_t/b\374\256"..., 16384) = 16384
19:40:33.794741 read(55, "\3\0l8\207|\231E\257\243\21 \277h\347_\362\312\261cR[\27"..., 16384) = 16384
19:40:33.794845 read(55, "\202\263\321\225\211\360G\22X\f,: 3\246Ah\16\371\234`\25"..., 16384) = 16384
19:40:33.794947 read(55, "\332\200:\3\315\27\342Dy\355\365c\2178\214\2{\274 \364"..., 16384) = 16384
19:40:33.795048 read(55, "\323<T\331\245\7W\207\260\265\334\246\335w\vX\246\233\33"..., 16384) = 16384
19:40:33.795153 read(55, "\23\v\252Y\204\266\253\230M\234\3058\200\322\236N\256\256"..., 16384) = 16384
19:40:33.795271 read(55, "?n\341\271\0\323\36\366\"\263I\6Gz\"\26\306\224\247\5\325"..., 4096) = 4096
19:40:34.509414 _llseek(55, 12677120, [12677120], SEEK_SET) = 0
19:40:34.509512 read(55, "\307y\223]5\265\374\222\v\371\10S\351d\0226w\305P7\252"..., 16384) = 16384
19:40:34.509629 read(55, "\26\271\211\212V\23h]\335ak\254u\260\323j%\231!\247u\241"..., 16384) = 16384
19:40:34.509721 read(55, "\2144\334\266\372\22\365S\257\313uK\354\363\t% 5\37^\32"..., 16384) = 16384
19:40:34.509813 read(55, "\"CV\235Xc8\206}\363\02597\202\302\336\236\215\253\'}\222"..., 16384) = 16384
19:40:34.509905 read(55, "Q\34\332\213OTnK\34\256\265\37\236\272\0319\257%<\302\25"..., 16384) = 16384
19:40:34.509998 read(55, "F\263h\354\31SFD`\34I\310\203v\374j\230\31_t/b\374\256"..., 16384) = 16384
19:40:34.510090 read(55, "\3\0l8\207|\231E\257\243\21 \277h\347_\362\312\261cR[\27"..., 16384) = 16384
19:40:34.510197 read(55, "\202\263\321\225\211\360G\22X\f,: 3\246Ah\16\371\234`\25"..., 16384) = 16384
19:40:34.510288 read(55, "\332\200:\3\315\27\342Dy\355\365c\2178\214\2{\274 \364"..., 16384) = 16384
19:40:34.510379 read(55, "\323<T\331\245\7W\207\260\265\334\246\335w\vX\246\233\33"..., 16384) = 16384
19:40:34.510473 read(55, "\23\v\252Y\204\266\253\230M\234\3058\200\322\236N\256\256"..., 16384) = 16384
19:40:34.510564 read(55, "?n\341\271\0\323\36\366\"\263I\6Gz\"\26\306\224\247\5\325"..., 4096) = 4096
19:40:34.510644 brk(0x8be4000) = 0x8be4000
19:40:34.530938 brk(0x8bd4000) = 0x8bd4000
19:40:34.531038 brk(0x8bc4000) = 0x8bc4000
19:40:34.531091 brk(0x8bb4000) = 0x8bb4000
19:40:34.665657 _llseek(55, 12861440, [12861440], SEEK_SET) = 0
19:40:34.665712 read(55, "\264\223\2317)\312\205Nd\340\340\275\22\337S\336\342\205"..., 16384) = 16384
19:40:34.665807 read(55, "\337\322\2554\316\273\336\272\214\323<\251UiO\227L\201"..., 16384) = 16384
19:40:34.665897 read(55, "e\242\204r\333\230\315b\333\224\24\355J/\357y\317\262\355"..., 16384) = 16384
19:40:34.665989 read(55, "\303\t\246\235d\211\"\325;\"F\376i\37\237]\364D\206i\375"..., 16384) = 16384
19:40:34.666084 read(55, "l\n\313\24\317\361f\217i\366\332\36664\3678\23\2747\271"..., 16384) = 16384
19:40:34.666190 read(55, "p2\3770\f\2\2108\232\373\'\4Q\305O\223X&\214\2667`F\32"..., 16384) = 16384
19:40:34.666373 read(55, "t\336N\230)\322r]\353e\337\342\354\363\17<177k>|\225\177mf\236@l\257t\1\240\340&\351\226O"..., 16384) = 16384
19:40:34.666559 read(55, "&\377\375\16\217\21\330\372z\264$\317\350hb\305\263\213"..., 16384) = 16384
19:40:34.666649 read(55, "\231\275\270E\351\16e\241\245\226\235%\232\307\347Bfj\4"..., 16384) = 16384
19:40:34.666740 read(55, "\22R\266\305#,B\221\305L\235\376r\273W\212\10\224\"U\315"..., 16384) = 16384
19:40:34.666831 read(55, "\\\244\35\25\335u\206\252X$\370q\257_.\303\317y\242\33"..., 4096) = 4096
19:40:34.666913 brk(0x8be4000) = 0x8be4000
19:40:34.684111 mmap2(NULL, 380928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e34000
19:40:34.686481 brk(0x8bd4000) = 0x8bd4000
19:40:34.686577 brk(0x8bc4000) = 0x8bc4000
19:40:34.686632 brk(0x8bb4000) = 0x8bb4000
19:40:35.797663 _llseek(55, 221573120, [221573120], SEEK_SET) = 0
19:40:35.797721 read(55, "\37?.\241P&\227y\35S9\367\2#AE\336\314`\275\255T\246+9"..., 16384) = 16384
19:40:35.797832 read(55, "\r\260$,\345l\326\322\v\347+<6u>\354j\23\260(\214\213\234\310\267\342"..., 16384) = 16384
19:40:35.798309 read(55, "\323Q\27\32\17\21_i\225i\2061\355\240\267em\'4\300O\241"..., 16384) = 16384
19:40:35.798401 read(55, "\"\301\274\260\"f\10\30\243j\324\177\301\350<200n>\230\rl\214=6M8\330"..., 16384) = 16384
19:40:35.798770 read(55, "\236X\33\326\r\330\315\303\212.\3\347\22\0044~\331\22="..., 4096) = 4096
19:40:35.800717 _llseek(55, 173854720, [173854720], SEEK_SET) = 0
19:40:35.800815 read(55, "\4\36[\234\200R\373\364>\'\252gjH\355|JW\t\342;\257P\375"..., 16384) = 16384
19:40:35.800938 read(55, "g}\271\333\221\204a\"\177\346\267\16!\245\370y\273\203"..., 16384) = 16384
19:40:35.801031 read(55, "\254\331\334\276\210\36u\325\371d\375\v\277\0\213v\26\30"..., 16384) = 16384
19:40:35.801123 read(55, "@\354\245<h>\177E\331\233\16\224\264=C\343>"..., 16384) = 16384
19:40:35.801698 read(55, "\240\272L\23\325\367&\"&\311\10Q\3461\360\36\370\3^\333"..., 16384) = 16384
19:40:35.801790 read(55, "\245\226*&\372Su\342a\372\336%\200\352\206\255\240\237"..., 16384) = 16384
19:40:35.801880 read(55, "A\227 \252c\335^\313\230\241o\17(C\31\307\315*\206d\3s"..., 4096) = 4096
19:40:37.128501 _llseek(55, 221573120, [221573120], SEEK_SET) = 0
19:40:37.128600 read(55, "\37?.\241P&\227y\35S9\367\2#AE\336\314`\275\255T\246+9"..., 16384) = 16384
19:40:37.128714 read(55, "\r\260$,\345l\326\322\v\347+<6u>\354j\23\260(\214\213\234\310\267\342"..., 16384) = 16384
19:40:37.129193 read(55, "\323Q\27\32\17\21_i\225i\2061\355\240\267em\'4\300O\241"..., 16384) = 16384
19:40:37.129285 read(55, "\"\301\274\260\"f\10\30\243j\324\177\301\350<200n>\230\rl\214=6M8\330"..., 16384) = 16384
19:40:37.129661 read(55, "\236X\33\326\r\330\315\303\212.\3\347\22\0044~\331\22="..., 4096) = 4096
|
in comparison, mlnet-2.8.2 does reads of 10240 bytes, one read per fd
| Code: |
_llseek(130, 62238720, [62238720], SEEK_SET) = 0
read(130, "\300\235g\361C\200-1y\232N\236\336e\272_\306\r\313JJ\272"..., 10240) = 10240
_llseek(130, 62248960, [62248960], SEEK_SET) = 0
read(130, "?\312\204W\256\352g\354\325\232\274\273e\342g\331T\300"..., 10240) = 10240
_llseek(130, 62259200, [62259200], SEEK_SET) = 0
read(130, "h\366\202\256S\313\343\336>L\237\201\333t\342U\270\207"..., 10240) = 10240
|
|
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Wed Apr 04, 2007 10:34 pm Post subject: |
|
|
| lugdunum wrote: | | in comparison, mlnet-2.8.2 does reads of 10240 bytes, one read per fd |
Since MLDonkey 2.8.3 supports eMule-style upload compression, from Changelog:
| Quote: | 2007/01/11
5665: EDK: Support compressed upload, implement file read cache (TripleM)
new options:
- ED2K_upload_compression to enable compressed upload, default true
- ED2K_upload_compression_threshold, default 2000 bytes
Size difference in bytes between one zone (180 kBytes) and its compressed
counterpart, which has to occure, to send compressed parts instead of plain.
- ED2K_upload_compression_level, Zlib compression level, default 9
- ED2K_upload_compression_table_size, default 20 |
eMule file requests consist of up to three zones of 184320 bytes each.
This data can be uploaded compressed or uncompressed.
In order to compress it, MLDonkey needs to read the whole zone from the
HDD at once. Uploading takes place in blocks of 10240 bytes, regardless if
compressed or not.
MLDonkey 2.8.2 and earlier read each 10k block before sending it, because
these versions do not support compressed upload.
Your strace shows this behaviour.
MLDonkey 2.8.3/4 now reads a 180k zone at once (or less if less data is requested),
stores it in a cache, compresses it if needed (ED2K-upload_compression = true)
and sends the data in 10k blocks.
Your strace of MLDonkey 2.8.3/4 showed this:
| Quote: | read(20, "\t\333WK1\37\240q\\\30\304\260\17H\254!o\273\3\373\317"..., 16384) = 16384
read(20, "\266\227\302\357{\225\211]\277\226\375\340\243\267\326"..., 16384) = 16384
read(20, "ly\367\10\263C\'\236\360)\367f\311q\247\277I\216\237C\317"..., 16384) = 16384
read(20, "\205\262\325\365\357\373\322\357s\306i\f\336\363\257I\274"..., 16384) = 16384
read(20, "\301\357\361_wvi\377\27695\177\233W\314>?c]\377\264@\5"..., 16384) = 16384
read(20, "\314n\220>\34\nn\202Z\273K\323H\4xeX\35\276\342\261\326"..., 16384) = 16384
read(20, "&\255\2226\377\302%`z\354\256\37\234\r\234Og\tN\232\376"..., 16384) = 16384
read(20, "z\250!\211\25\222\356.\246J\374\263\373}w.T\246ZtsY\304"..., 16384) = 16384
read(20, "\255l\323r\2674\347h\353L\217\354\237\260\v\22\257\244"..., 16384) = 16384
read(20, "\200\364\242\'\327\342\235qSJ\271\tq\\#\32\243{\317\5x"..., 16384) = 16384
read(20, "_\354\245\351\257\371oVF\322\326\213\310\233\377\226\331"..., 16384) = 16384
read(20, "\3362\\>\350\352\261\270\204\\\251\245j\276\273h\3168H"..., 4096) = 4096 |
which is 11 * 16384 + 4096 = 184320 byte.
Verifying this with MLDonkey option verbosity = "file" confirms this:
| Quote: | | 2007/04/05 00:02:32 [Ux32] really_read some_file 604241920 184320 |
To send a 180k block MLDonkey 2.8.3/4 needs 12 reads from HDD, while
earlier versions needed 18 reads (184320 / 10240), so newer versions should
be more efficient, but need slightly more RAM to store the complete zone in memory.
Here the same situation with MLDonkey 2.8.2:
| Quote: | | read(16, "\210\243\270r\343\307\375_\21\276\375\271\327\221\376\215"..., 10240) = 10240 |
Lots of reads with 10240 bytes which are connected to this MLDonkey log:
| Quote: | | 2007/04/05 00:25:16 [Ux32] really_read some_file 522137600 10240 |
Now to the question why newer MLDonkey versions need more reads.
What bothers me is that your MLDonkey seems to read the same data more than once:
| Quote: | 19:40:33.243977 _llseek(55, 12677120, [12677120], SEEK_SET) = 0
19:40:33.244034 read(55, "\307y\223]5\265\374\222\v\371\10S\351d\0226w\305P7\252"..., 16384) = 16384
19:40:33.794044 _llseek(55, 12677120, [12677120], SEEK_SET) = 0
19:40:33.794098 read(55, "\307y\223]5\265\374\222\v\371\10S\351d\0226w\305P7\252"..., 16384) = 16384
19:40:34.509414 _llseek(55, 12677120, [12677120], SEEK_SET) = 0
19:40:34.509512 read(55, "\307y\223]5\265\374\222\v\371\10S\351d\0226w\305P7\252"..., 16384) = 16384 |
During my tests I could not see such a behaviour, neither in MLDonkey log nor in strace.
Could you please check MLDonkey log with verbosity set to "file" and
compare it with strace output?
To change verbosity use MLDonkey command "set verbosity file"
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
lugdunum
neophyte
Joined: 18 Nov 2003
Posts: 38
Location: france
|
| Posted: Wed Apr 04, 2007 11:14 pm Post subject: |
|
|
Most probably the problem comes from a too small cache.
What happens if I have 100 active uploads, but only 20 slot in the cache ?
(upload_compression_table_size = 20)
My guess is you evict one entry, do a full read of 184320 bytes, compress it.
select some bytes (10240 if I understood you) to send on a socket.
Reading from disk is not really expensive, since OS cache it, but compressing the whole 184320 bytes is the killer. |
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Wed Apr 04, 2007 11:30 pm Post subject: |
|
|
| lugdunum wrote: | | but compressing the whole 184320 bytes is the killer. |
You have two choices to test, disable upload compression or increase
upload_compression_table_size.
According to TripleMīs research of eMule sourcecode
http://www.mldonkey.org/forum/viewtopic.php?p=42385#42385
he found out that a 180k zone has to be compressed as a whole,
then uploaded in packets of 10k each. This is the reason for the
implementation of the upload cache.
Can I assume that your problem is a too small upload_compression_table_size
for your high-volume upload? What about implementing a hard-coded
minimum for upload_compression_table_size depending on the number of
upload slots?
EDIT: With verbosity "up" you can see how the cache is used.
Watch out for entries like "Cache Miss" and "Cache Hit"
EDIT 2: The description of option upload_compression_table_size confirms this:
| Quote: | | to reduce diskaccess and repeated compression to a minimum, size should be at least the number of total upload slots |
But better have a hard-coded minimum instead of a description nobody reads  Please test this patch:
| Code: | --- ././src/networks/donkey/donkeyOptions.ml 2007-02-19 22:19:44.000000000 +0100
+++ ././src/networks/donkey/donkeyOptions.ml 2007-04-05 01:49:22.000000000 +0200
@@ -233,14 +233,13 @@
~restart: true
"Size of the cache table in entries (ca. 2 * 180 kbytes). zones have to be
compressed at once, but only parts of it are sent at a time (10 kbytes).
- to reduce diskaccess and repeated compression to a minimum, size should be
- at least the number of total upload slots. restart of core is required."
+ Minimum value is the number of total upload slots."
int_option 20
let _ =
option_hook upload_compression_table_size (fun _ ->
- if !!upload_compression_table_size < 1 then
- upload_compression_table_size =:= 1
+ if !!upload_compression_table_size < !!max_upload_slots then
+ upload_compression_table_size =:= !!max_upload_slots
)
let connected_server_timeout = define_expert_option donkey_section ["connected_server_timeout"] |
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
lugdunum
neophyte
Joined: 18 Nov 2003
Posts: 38
Location: france
|
| Posted: Thu Apr 05, 2007 10:34 pm Post subject: |
|
|
It doesnt work.
when upload_compression_table_size == max_upload_slots , mldonkey starts to behave incorrectly after 15 minutes or so.
Version 2.8.2 survives more than 20 hours... |
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Thu Apr 05, 2007 10:38 pm Post subject: |
|
|
| lugdunum wrote: | | Version 2.8.2 survives more than 20 hours... |
Did you try to disable upload compression?
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
lugdunum
neophyte
Joined: 18 Nov 2003
Posts: 38
Location: france
|
| Posted: Thu Apr 05, 2007 10:48 pm Post subject: |
|
|
yes... same problem.
What about fd cache_size = 50 ?
(src/utils/lib/unix32.ml) |
|
| Back to top |
|
|
spiralvoice
Sage
Joined: 06 Jan 2003
Posts: 3982
Location: Germany
|
| Posted: Thu Apr 05, 2007 11:09 pm Post subject: |
|
|
| lugdunum wrote: | What about fd cache_size = 50 ?
(src/utils/lib/unix32.ml) |
I think this is unrelated:
http://cvs.savannah.nongnu.org/viewcvs/mldonkey/src/utils/lib/unix32.ml?annotate=1.68&root=mldonkey
line 37 has been unchanged since the creation of the file four years ago.
When you call the MLDonkey command "mem_stats", which value for
max cache_size in section Unix32 is printed? Here I have 55.
Between MLDonkey 2.8.2 and 2.8.3 there were lots of changes which
may affect the CPU usage. Unfortunately I am not able to reproduce
the problem here due to a small DSL connection (2000/384).
Here is the Changelog between 2.8.2 and 2.8.3:
http://cvs.savannah.nongnu.org/viewcvs/mldonkey/distrib/ChangeLog?root=mldonkey&r1=1.1118&r2=1.1178
The only way to find the bug is to find the day it was introduced.
Please get CVS checkouts for each day mentioned in Changelog,
compile it and test which is the oldest version producing the bug.
Example: To get CVS code from 2006/12/01 use this command:
cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/mldonkey co -D 20061201 -P mldonkey
Here is a list of days which may be of interest:
2006/12/03
2007/01/08
2007/01/11 (compressed upload)
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks |
|
| Back to top |
|
|
lugdunum
neophyte
Joined: 18 Nov 2003
Posts: 38
Location: france
|
| Posted: Thu Apr 05, 2007 11:27 pm Post subject: |
|
|
Well... I dont know ocaml nor mldonkey, so thats tricky...
But FD cache is cleary buggy
or is it a garbage collector that could explain all those munmap() calls ???
01:25:05.096551 munmap(0xa630b000, 253952) = 0
01:25:05.096754 munmap(0xa6349000, 253952) = 0
01:25:05.096854 munmap(0xa6387000, 253952) = 0
01:25:05.096953 munmap(0xa63c5000, 253952) = 0
01:25:05.097067 munmap(0xa6403000, 253952) = 0
01:25:05.097173 munmap(0xa6441000, 253952) = 0
01:25:05.097275 munmap(0xa647f000, 253952) = 0
01:25:05.097395 munmap(0xa64bd000, 253952) = 0
01:25:05.097498 munmap(0xa64fb000, 253952) = 0
01:25:05.097604 munmap(0xa6539000, 253952) = 0
01:25:05.097706 munmap(0xa6577000, 253952) = 0
01:25:05.097814 munmap(0xa65b5000, 253952) = 0
01:25:05.097918 munmap(0xa65f3000, 253952) = 0
01:25:05.098020 munmap(0xa6631000, 253952) = 0
01:25:05.098128 munmap(0xa666f000, 253952) = 0
01:25:05.098233 munmap(0xa66ad000, 253952) = 0
01:25:05.098335 munmap(0xa66eb000, 253952) = 0
01:25:05.098460 munmap(0xa6729000, 253952) = 0
01:25:05.098561 munmap(0xa6767000, 253952) = 0
01:25:05.098723 munmap(0xa67a5000, 253952) = 0
01:25:05.098836 munmap(0xa67e3000, 253952) = 0
01:25:05.098940 munmap(0xa6821000, 253952) = 0
01:25:05.099046 munmap(0xa685f000, 253952) = 0
01:25:05.099157 munmap(0xa689d000, 253952) = 0
01:25:05.099261 munmap(0xa68db000, 253952) = 0
01:25:05.099381 munmap(0xa6919000, 253952) = 0
01:25:05.099483 munmap(0xa6957000, 253952) = 0
01:25:05.099588 munmap(0xa6995000, 253952) = 0
01:25:05.099694 munmap(0xa69d3000, 253952) = 0
01:25:05.099797 munmap(0xa6a11000, 253952) = 0
01:25:05.099906 munmap(0xa6a4f000, 253952) = 0
01:25:05.100010 munmap(0xa6a8d000, 253952) = 0
01:25:05.100113 munmap(0xa6acb000, 253952) = 0
01:25:05.100218 munmap(0xa6b09000, 253952) = 0
01:25:05.100319 munmap(0xa6b47000, 253952) = 0
01:25:05.100440 munmap(0xa6b85000, 253952) = 0
01:25:05.100543 munmap(0xa6bc3000, 253952) = 0
01:25:05.100649 munmap(0xa6c01000, 253952) = 0 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © phpBB Group
|
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
