Hi you all!
I would like to know you some of you experienced a 100% CPU usage by dtnd. If so in which case, what triggered this behavior and how was it corrected (if it was).
As for me, some of the node I run consume 100% of CPU and still cannot find out why.
Any help or suggestion welcome. Have a nice day! --- The dtnd version is 1.0.1, as for the configuration: local_uri = dtn://$HOSTNAME logfile = /dev/null discovery_address = 224.0.0.142 discovery_timeout = 1 discovery_interval = 1 net_interfaces = eth net_eth_type = tcp net_eth_interface = ethwe0 net_eth_port = 4556 keepalive_timeout = 5 routing = flooding static1_proto = tcp static1_immediately = yes static1_global = no dht_enable_ipv6 = no dht_enabled = yes limit_bundles_in_transit = 100
Best regards, --- Auzias Maël auzias.net https://www.auzias.net/en/ - vcard https://www.auzias.net/auzias.vcf - thesis http://people.irisa.fr/Mael.Auzias/ *GSM: 0033 695 118 774*
Hi,
Superfull storage, or corrupted SQL databases are known to sometimes have this effects, but if I see it right, you are using memory storage. Is the node still working with 100% CPU usage? Any suspicious things in the log? Are you running out of RAM?
Sebastian
On 06 Apr 2016, at 16:20, Maël Auzias ibrdtn@auzias.net wrote:
Hi you all!
I would like to know you some of you experienced a 100% CPU usage by dtnd. If so in which case, what triggered this behavior and how was it corrected (if it was).
As for me, some of the node I run consume 100% of CPU and still cannot find out why.
Any help or suggestion welcome. Have a nice day!
The dtnd version is 1.0.1, as for the configuration: local_uri = dtn://$HOSTNAME logfile = /dev/null discovery_address = 224.0.0.142 discovery_timeout = 1 discovery_interval = 1 net_interfaces = eth net_eth_type = tcp net_eth_interface = ethwe0 net_eth_port = 4556 keepalive_timeout = 5 routing = flooding static1_proto = tcp static1_immediately = yes static1_global = no dht_enable_ipv6 = no dht_enabled = yes limit_bundles_in_transit = 100
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
Hi! Thanks for your reply.
The node was stopped few days again but the RAM usage was OK (it had still a few free gigabytes). The log did not shown anything suspicious.
Is there anything in the conf file I could change to test? (Note that I rather not leave the memory storage)
Best regards, --- Auzias Maël auzias.net https://www.auzias.net/en/ - vcard https://www.auzias.net/auzias.vcf - thesis http://people.irisa.fr/Mael.Auzias/ *GSM: 0033 695 118 774*
On Sun, Apr 10, 2016 at 1:55 PM, Sebastian Schildt schildt@ibr.cs.tu-bs.de wrote:
Hi,
Superfull storage, or corrupted SQL databases are known to sometimes have this effects, but if I see it right, you are using memory storage. Is the node still working with 100% CPU usage? Any suspicious things in the log? Are you running out of RAM?
Sebastian
On 06 Apr 2016, at 16:20, Maël Auzias ibrdtn@auzias.net wrote:
Hi you all!
I would like to know you some of you experienced a 100% CPU usage by
dtnd.
If so in which case, what triggered this behavior and how was it
corrected (if it was).
As for me, some of the node I run consume 100% of CPU and still cannot
find out why.
Any help or suggestion welcome. Have a nice day!
The dtnd version is 1.0.1, as for the configuration: local_uri = dtn://$HOSTNAME logfile = /dev/null discovery_address = 224.0.0.142 discovery_timeout = 1 discovery_interval = 1 net_interfaces = eth net_eth_type = tcp net_eth_interface = ethwe0 net_eth_port = 4556 keepalive_timeout = 5 routing = flooding static1_proto = tcp static1_immediately = yes static1_global = no dht_enable_ipv6 = no dht_enabled = yes limit_bundles_in_transit = 100
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or
adjust
!! your settings, send a mail message to <
ibr-dtn-request@ibr.cs.tu-bs.de>
!! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
-- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
participants (2)
-
Maël Auzias -
Sebastian Schildt