Approaching the limit on PV entries

hi

I've done Upgrade from freeBSD 7.0 Release to 7.3 and I'm getting a lot of these messages:
Code:
[B]Approaching the limit on PV entries, consider increasing either the
vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable[/B]

Code:
# sysctl vm.pmap
vm.pmap.pmap_collect_active: 0
vm.pmap.pmap_collect_inactive: 0
vm.pmap.pv_entry_spare: 181432
vm.pmap.pv_entry_allocs: 348739086
vm.pmap.pv_entry_frees: 348574102
vm.pmap.pc_chunk_tryfail: 0
vm.pmap.pc_chunk_frees: 1320995
vm.pmap.pc_chunk_allocs: 1322026
vm.pmap.pc_chunk_count: 1031
vm.pmap.pv_entry_count: 164984
vm.pmap.pde.promotions: 0
vm.pmap.pde.p_failures: 0
vm.pmap.pde.mappings: 0
vm.pmap.pde.demotions: 0
[B]vm.pmap.shpgperproc: 200[/B]
[B]vm.pmap.pv_entry_max: 922992[/B]
vm.pmap.pg_ps_enabled: 0
 
BTW I cannot change using sysctl
Code:
# sysctl vm.pmap.pv_entry_max=1745520
[B][color="Red"]sysctl: oid 'vm.pmap.pv_entry_max' is read only[/color][/B]
 
Thx, I can add in /boot/loader.conf, but first of all I must know which values should I set for vm.pmap.shpgperproc and vm.pmap.pv_entry_max.
 
I added the following lines in /boot/loader.conf:
Code:
# cat /boot/loader.conf
sound_load="YES"
snd_ich_load="YES"
linux_load="YES"

[B][color="DarkGreen"]vm.pmap.pde.mappings=68
vm.pmap.shpgperproc=500
vm.pmap.pv_entry_max=1743504[/color][/B]
and now this problem seems to be solved.
 
Digging on an old thread, does anyone know what those values stand for and what might cause the need for adjusting them ?

I have googled a bit but haven't come up with a right answer yet.

Thanks,

George
 
Sylhouette said:
i found this in the mailling list

http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029076.html

it suggest to use super pages.
vm.pmap.pg_ps_enabled = 1

Are you using squid or dansguardian too on that machine?

regards
Johan Hendriks
Only Apache with PHP. I saw this message yesterday after almost 3 years with no issues. I also checked my logs and didn't find anything in particular at the time this message appeared.
The only thing out of the usual yesterday was a sudden increase in swap usage which I saw in my munin graphs. 2 spikes.
 

Attachments

  • swap-day.png
    swap-day.png
    15.1 KB · Views: 3,113
The setting is gone in 8.3 and I assume also 9.x, does this mean the limitation is removed altogether or is the value now hardcoded?
 
chrcol said:
The setting is gone in 8.3

Code:
ku-new:home/support# uname -prs
FreeBSD 8.3-RELEASE-p3 amd64

ku-new:home/support# sysctl vm.pmap.shpgperproc
vm.pmap.shpgperproc: 200

ku-new:home/support# sysctl vm.pmap.pv_entry_max
vm.pmap.pv_entry_max: 4274297

Why do you think these setting are gone?
 
sorry to bring this topic up. I got the error message
an 26 18:09:05 freebsd1 kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.

when I check my vmap
Code:
vm.pmap.shpgperproc: 200
vm.pmap.pv_entry_max: 3234117

which is much higher than ccc. Anyone knows what is this? and what the value I need to put it in? and I am using FreeBSD 9.0-RELEASE-p5 amd64
 
vm.pmap.shpgperproc has a default value of 200.
Try enabling superpages first:

Code:
vm.pmap.pg_ps_enabled = 1

If the message still continues, try increasing vm.pmap.shpgperproc by 50 until the message goes away.
 
@adri I will give a try. However to know the effect of your suggestion, might not be possible. Since the warning appeared without any reason that I know of, and after the server been used for 1 year+.
 
Binyo,

The only way to know, when the vm.pmap.shpgperproc is high enough, is to increment it and see if the message returns after a while.
I am currently using about 750 on one of my servers, but this might be due to 1 process using 2Gb of VM rapidly forking about 15 times.

Adri.
 
adri said:
vm.pmap.shpgperproc has a default value of 200.
Try enabling superpages first:

Code:
vm.pmap.pg_ps_enabled = 1

If the message still continues, try increasing vm.pmap.shpgperproc by 50 until the message goes away.

I got the message from my new office desktop, which I just installed freebsd 9 on external usb, and boot from there. your suggestion didn't work, the message appeared right after boot up, before the logging prompt (it appeared every boot, except single user). I tried to increased to 250, still error... and I couldn't logged in just hang. So I increased to
Code:
vm.pmap.pv_entry_max="3000000"
and finally I saw the login prompt.

I was really confused... because I couldn't see the login prompt, except hang with the message, and I builded world with the source code that I took a week ago, and also the ports. I got KDE4 problem with dbus for regular users, but gnome working fine for every user, and so far not so many installed applications yet. Anyone knows what the problem here is? because I boot from USB (this is my first time installed and booted from USB) ?
 
I know this is an old thread, but I ran into this the other day on an Amazon EC2 instance.

Code:
FreeBSD hostname.here 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Jan  5 22:56:03 UTC 2012     root@ip-10-17-24-248:/usr/obj/usr/src/sys/XENHVM  amd64
I had just added a drive and enabled swap on it; previously there had been no swap space.

Coincidentally, I had an issue where the Apache error log file was being spammed with the following due to incorrect use of the -l flag in the rotatelogs directive in the conf of several sites. That was causing a considerable load on the disks containing log files. One or both of these problems were slowing Apache down.

Code:
Usage: /usr/local/sbin/rotatelogs [-l] [-f] <logfile> {<rotation time in seconds>|<rotation size in megabytes>} [offset minutes from UTC]

Add this:

TransferLog "|/usr/local/sbin/rotatelogs /some/where 86400"

or

TransferLog "|/usr/local/sbin/rotatelogs /some/where 5M"

to httpd.conf. The generated name will be /some/where.nnnn where nnnn is the
system time at which the log nominally starts (N.B. if using a rotation time,
the time will always be a multiple of the rotation time, so you can synchronize
cron scripts with it). At the end of each rotation time or when the file size
is reached a new log is started.
UTC offset parameter is not valid with -l

In any case, I resolved the issue by gradually raising the vm.pmap.shpgperproc value until the problem went away, as suggested here. I realized the log spam issue right after that, upon follow-up investigation.

I don't know enough to even know what PV entries are, but I am curious if the two issues could be related? Can anyone chime in on this?
 
Back
Top