From: Steve <k4...@ta...> - 2001-11-26 20:01:34
|
Several times over the last week I've seen something new. aprsd suddenly begins conuming all the available CPU time on the primary findu machine. There are three processes sharing in this load. The input queue's reported by netstat -t are in the 70k range for several connections, making me think the server isn't processing data from these ports. However, the server is still processing some data, because the findu parser (the only connection to the server) is still getting data, there are no gaps in the database, and the watchdog is not triggered. When I discover it my first priority is returning the server to a functioning state, which means executing an aprsd.init stop, and letting the watchdog restart. I haven't looked too closely at the situation because if this priority. Anybody else ever seen anything like it? On a related issue, is there an update on the filtering plans? The fact that this filters out long posits is the last remaining thing keeping me from returning the primary server to duty as www.findu.com. I really would like to do it, the secondary server just doesn't have the disk throughput the load requires these days... Steve K4HG |
From: Chuck B. <cb...@vi...> - 2001-11-26 20:12:04
|
On Monday 26 November 2001 03:01 pm, Steve wrote: .: Several times over the last week I've seen something new. aprsd suddenly .: begins conuming all the available CPU time on the primary findu machine. .: There are three processes sharing in this load. The input queue's .: reported by netstat -t are in the 70k range for several connections, .: making me think the server isn't processing data from these ports. .: However, the server is still processing some data, because the findu .: parser (the only connection to the server) is still getting data, there .: are no gaps in the database, and the watchdog is not triggered. .: .: When I discover it my first priority is returning the server to a .: functioning state, which means executing an aprsd.init stop, and letting .: the watchdog restart. I haven't looked too closely at the situation .: because if this priority. .: .: Anybody else ever seen anything like it? I see this occasionally. I believe a thread is being locked and not released somewhere. I found one of these already. This is on my todo list to track down. .: .: On a related issue, is there an update on the filtering plans? The fact .: that this filters out long posits is the last remaining thing keeping me .: from returning the primary server to duty as www.findu.com. I really .: would like to do it, the secondary server just doesn't have the disk .: throughput the load requires these days... Filtering plans? I thought the plan was not to filter. The dev code that I am currently running on first has nearly all filtering removed. I plan on synching this with CVS soon. Chuck |
From: Brian D H. <bdh...@c4...> - 2001-11-26 20:14:43
|
Steve, Are you running the most recent 2.2.1 code from CVS or some earlier version? The filtering has been relaxed recently and you may find it works for you.. 73/N5VFF On Mon, 2001-11-26 at 14:01, Steve wrote: > Several times over the last week I've seen something new. aprsd suddenly > begins conuming all the available CPU time on the primary findu machine. > There are three processes sharing in this load. The input queue's > reported by netstat -t are in the 70k range for several connections, > making me think the server isn't processing data from these ports. > However, the server is still processing some data, because the findu > parser (the only connection to the server) is still getting data, there > are no gaps in the database, and the watchdog is not triggered. > > When I discover it my first priority is returning the server to a > functioning state, which means executing an aprsd.init stop, and letting > the watchdog restart. I haven't looked too closely at the situation > because if this priority. > > Anybody else ever seen anything like it? > > On a related issue, is there an update on the filtering plans? The fact > that this filters out long posits is the last remaining thing keeping me > from returning the primary server to duty as www.findu.com. I really > would like to do it, the secondary server just doesn't have the disk > throughput the load requires these days... > > Steve K4HG > > _______________________________________________ > Aprsd-devel mailing list > Apr...@li... > https://lists.sourceforge.net/lists/listinfo/aprsd-devel > |
From: Hamish M. <ha...@cl...> - 2001-11-26 21:31:50
|
On Mon, Nov 26, 2001 at 03:01:15PM -0500, Steve wrote: > Several times over the last week I've seen something new. aprsd suddenly > begins conuming all the available CPU time on the primary findu machine. > There are three processes sharing in this load. The input queue's > reported by netstat -t are in the 70k range for several connections, > making me think the server isn't processing data from these ports. > However, the server is still processing some data, because the findu > parser (the only connection to the server) is still getting data, there > are no gaps in the database, and the watchdog is not triggered. I saw this last week. I had lots of lots of aprsd threads running, but no connections were accepted (or at least no data was passed on them, I can't remember which). The length checks have been removed in the current CVS code, btw. My local RF users are much happier now. Hamish -- Hamish Moffatt VK3SB <ha...@de...> <ha...@cl...> |