ntpd high cpu usage

[totobel]

When transfering in FTP:

last pid: 8937; load averages: 1.37, 0.68, 0.28 up 0+19:36:00 10:40:14
53 processes: 1 running, 52 sleeping
CPU: 2.3% user, 0.0% nice, 23.3% system, 6.2% interrupt, 68.2% idle
Mem: 84M Active, 65M Inact, 281M Wired, 4224K Cache, 112M Buf, 1564M Free
Swap: 4096M Total, 4096M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
2045 root 1 71 0 4744K 2276K select 1 1:08 24.66% ntpd
8920 root 1 53 0 7260K 4292K zio->i 1 0:21 14.89% proftpd
8919 root 1 53 0 7260K 4292K zio->i 1 0:21 14.70% proftpd


This ntpd is going crazy ...
It may or may not be the cause of my slow transfer speed (200-250Mbits on a Pentium4 3ghz) ?

v. 8.0.2
Let me know if you'd like any more data

This guy here has noticed the same issues several months ago:
http://forums.freenas.org/showthread.php?31-How-to-boost-network-speed

 

[William Grzybowski]

Erm, what?

That only happens when you're transferring with FTP?

 

[totobel]

only in ftp, yes sir ;)
And i'm not the only one apparently

 

[louisk]

I saw a similar issue on a system with AFP instead of FTP. The "solution" ended up being a BIOS update.

 

[totobel]

a bios update ? that's also weird ...
it's the weirdest problem ever this one

 

[peterh]

I _think_ ntpd is "locking itself " with the scheduler. It might want ro stay in execution, but each
timetick it only uses a small amount. I've seen similar symptoms with other brands of un*x and
simular types of applications.

After a while ntpd will ease down ( when it feels that clocks are syncronized ) and seem to consume less.
This system have been running for a while :

last pid: 5648; load averages: 0.01, 0.03, 0.00 up 56+22:08:13 17:41:14
58 processes: 1 running, 57 sleeping
CPU: 0.2% user, 0.0% nice, 2.3% system, 0.6% interrupt, 97.0% idle
Mem: 64M Active, 223M Inact, 6975M Wired, 8K Cache, 207M Buf, 595M Free
Swap:

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
96255 root 1 44 0 48072K 9080K select 1 160:18 0.29% afpd
1498 root 1 44 0 11776K 1912K select 1 246:07 0.00% ntpd
15790 avahi 1 44 0 16932K 2552K select 0 34:26 0.00% avahi-daem
8560 root 4 44 0 5684K 960K rpcsvc 1 24:40 0.00% nfsd

 

[totobel]

so you mean it's "normal" ?
nothing can be done to improve it ?

 

[peterh]

It's an effect of a task that "wants to run" ( resides in "Runnable state" )but executes only a few instructions at each scheduling cycle.
It's won't slow things down, you can keep it this way.

 

[gcooper]

The problem is actually probably that ntp listens on UDP, so if you have a service slamming UDP (afp if invoked via the Finder, etc), it will slam other services that listen on UDP.

 

[peterh]

Uhh ? One process listening on one udp port will not affect other processes listening on other ports . They are separated like several files are separated.

 

[gcooper]

Uhh ? One process listening on one udp port will not affect other processes listening on other ports . They are separated like several files are separated.

Are you sure about that :)..? Give it a try -- you might be surprised.

 

[peterh]

yes.
a socket is a socket, it may be u datagram ( udp) socket a stream socket (tcp), a unix-domain ( iso etc) but it's still a socket
Each socket descriptor works like a file descriptor ( one might say is a file descriptor) and is just a handle to a open file.

If a process that has an outstandig select() on socket A is affected by a udp packet arriving on socket b then something is broken.
Do you have example code (and environment) that shows broken behaviour of a socket ?

 

[bobfandango]

Seeing same problem with AFP

When time machine does its backups, ntpd use goes through the roof. I have not seen this with NFS or Samba shares.

The machine is an N40L with 8gigs RAM and running FreeNAS 8.0.3

Anyone know why this is happening? Seems like a bug...


last pid: 36759; load averages: 3.81, 3.16, 2.71 up 2+20:40:51 12:22:45
51 processes: 3 running, 48 sleeping

Mem: 142M Active, 806M Inact, 5965M Wired, 169M Cache, 196M Buf, 712M Free
Swap: 8192M Total, 904K Used, 8191M Free


PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
35990 root 1 105 0 48844K 4852K CPU0 0 24:18 42.29% afpd
1455 root 1 101 0 11780K 2292K RUN 1 15:21 23.00% ntpd
35699 avahi 1 55 0 16932K 2400K select 0 7:20 13.57% avahi-daemon

 

[gcooper]

I'll look into it this weekend.

 

[davorin]

Any new discoveries on the ntpd issue?

Also see this with 8.0.3 using afp at the moment:


PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
2625 root 1 4 0 48844K 5496K RUN 1 31:27 48.68% afpd
1752 root 1 103 0 11780K 2740K CPU1 0 21:42 31.98% ntpd
2001 avahi 1 71 0 16932K 2844K RUN 1 13:14 21.48% avahi-daemon

 

[peterh]

8.03, idle :
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
5794 root 1 44 0 48844K 7276K select 1 37:31 0.00% afpd
1544 root 1 44 0 11780K 2740K select 0 21:08 0.00% ntpd
4974 avahi 1 44 0 16932K 2844K select 1 10:23 0.00% avahi-daem
1947 root 7 44 0 64532K 8816K ucond 0 2:51 0.00% collectd


803, during timemachine to a zfs volume:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
54044 root 1 47 0 48844K 5488K select 1 0:02 6.88% afpd
1544 root 1 45 0 11780K 2740K select 1 21:09 1.56% ntpd
4974 avahi 1 44 0 16932K 2844K select 0 10:24 0.98% avahi-daem
5794 root 1 44 0 48844K 7276K select 1 37:32 0.00% afpd