Approaching the limit on PV entries
We upgrade to Server 5.3.53053 / Agent 5.3.53177 over the weekend. The upgrade went smoothly and the new agent version is getting swapped out as expected. Since then I've needed to reboot the K1000 a couple of times. The console window fills with the error message - Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the v.pmap.pv_entry_max sysctl. Then the swap file fills and the services start to hang due to lack of swap file space.
We have 3100+ client PCs reporting, we have't enabled any MIs or Scripts and the Agent Run / Inventory are at their default settings.
We'd like to modify these entries but cannot due to access restrictions. Has anyone else experienced this issue? If so how did you manage it?
Thanks
We have 3100+ client PCs reporting, we have't enabled any MIs or Scripts and the Agent Run / Inventory are at their default settings.
We'd like to modify these entries but cannot due to access restrictions. Has anyone else experienced this issue? If so how did you manage it?
Thanks
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
GillySpy
12 years ago
You would have to have support make any changes like that. Are you driving a new shiny kbox or a classic model ?
Posted by:
GillySpy
12 years ago
Oopps, hit enter there...so I'd check the munin graphs (settings->logs->System performance) and see if you can see any trends. Maybe move some schedules around? Change some jobs or limiters like throughput? or provisioning tasks you don't need anymore? Have you had your database optimized lately? None of those things are directly related to this error but overall system health or lack of solves a lot of problems without needing surgery.
Posted by:
jmarotto
12 years ago
Classic and no DB optimization to date. Went on line 9/2011 and have been playing since then. I'll look at throughput (one of those I hadn't checked) as the rest of the items you mentioned are monitored daily. I kind of figured support would have to make the changes but was courious if anyone else had encountered the message. I also don't usually monitor the console so closely but wanted to after the updates were applied.
The other item of note is the is Computer Inventory. Have picked up over 200 clients since Sunday evening. That's the biggest (fastest) jump we've had since some GPO changes in January.
The other item of note is the is Computer Inventory. Have picked up over 200 clients since Sunday evening. That's the biggest (fastest) jump we've had since some GPO changes in January.
Posted by:
ronco
12 years ago
jmaratto,
Did I hear you right? You have 3100+ machines checking in, but still have the default 2-hour Run/Inventory Interval? That's over 25 connections per minute!!! The sweet spot recommendation for that setting (allowing for all other processes/peak, etc.) is around 5 or 6 connections per minute. You might want to address that first. r2
Did I hear you right? You have 3100+ machines checking in, but still have the default 2-hour Run/Inventory Interval? That's over 25 connections per minute!!! The sweet spot recommendation for that setting (allowing for all other processes/peak, etc.) is around 5 or 6 connections per minute. You might want to address that first. r2
Posted by:
Roonerspism
12 years ago
ronco,
Thats not that drastic, we've got about 1600+ with a agent run interval of 20 mins, inventory every hour. Our Load average is only 0.35 with 82ish run connections a minute. In completely wireless environments like ours, with students who power down/sleep their machines every 45 minutes when moving between classes and only have 6 contact hours where we can guarantee they'll be here, these sort of high connection numbers are needed.
As far as the problem of the errors, I'd say deffinately check those munin logs, they are amazing. As Gilly said again too, old provisionings will slow things down and a reboot with DB Optimize could only improve things.
Thats not that drastic, we've got about 1600+ with a agent run interval of 20 mins, inventory every hour. Our Load average is only 0.35 with 82ish run connections a minute. In completely wireless environments like ours, with students who power down/sleep their machines every 45 minutes when moving between classes and only have 6 contact hours where we can guarantee they'll be here, these sort of high connection numbers are needed.
As far as the problem of the errors, I'd say deffinately check those munin logs, they are amazing. As Gilly said again too, old provisionings will slow things down and a reboot with DB Optimize could only improve things.
Posted by:
GillySpy
12 years ago
Because folks can have quite a variation in hardware, when i don't know the context I say start at 4-8 tasks per minute and ramp up. Inventory is just one type of task. Munin is your best friend. If you have picked up 200 clients that is what a 7% increase? The task throughput should put a cap on tasks at any one time. But at the very least you have 7% more amp connections then before. What is (or was) your task throughput ? What do your munin graphs tell you ?
Posted by:
Roonerspism
12 years ago
Sorry for late reply Ronco, peak weekly load average last week was 163, max for the week was 1.34. I'm not sure if this is particularly high or not but we never notice any sort of lag in the UI, helpdesk or tasks etc.
Posted by:
ronco
12 years ago
Roonerspism,
Did you really mean to say that your weekly Load Average was 163, or 1.63? r2
Did you really mean to say that your weekly Load Average was 163, or 1.63? r2
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.