04-12-2012 07:20 AM
Hello,
We have 2x PA-2050 devices in HA running 3.1.10 and I'm frustrating about commit time, it takes like 5-10 min.
Can I expect significant improvement, commit time speaking, with upgrade to 4.1.5 ?
Field experiences in commit time with 4.1.5 ?
Or should I think about PA-4000 platform ?
04-12-2012 07:55 AM
Im sure any update above 4.0.9 should improve this a lot. Give a try with 4.1.4 or 4.1.5. I should use the 4.1.4
Best regards
04-12-2012 11:37 AM
My suggestion is not upgrade because of commit performance. You should upgrade for a feature needed in your network or a bug fix that could not be back ported to 3.1. On the performance of commit, it depends on your configuration. In many cases the commit time will go down when upgrading to 4.1, but it may not change the commit time at all. I hope this helps.
04-12-2012 01:34 PM
We are a new Palo Alto customer, and although so far I'm liking the PA-500 HA cluster I'm setting up a great deal (after two evaluations of Palo Altos in the last few years), the extremely long commit times are one of my biggest issues with these firewalls. They take so long that I have gotten in the habbit of working on something else during the commit. This may be acceptable for this cluster, which is only for our PC Internet access and VPN gateway, but this may be a sticking point for us in considering Palo Altos for the lease replacement of our HA firewall cluster that's protecting our online application (which will have a far more complicated configuration). I would like to think that this is a high priority for Palo Alto Networks to get resolved in future releases (we are on 4.1.4 right now, and these firewalls are not yet in production).
04-12-2012 10:53 PM
Thank's .. since the upgrade seams not solve the commit problem, what are the configuration optimizations that can, considerably, help this issue ?
How can I find why my commits take 5-10 min !!
slow commit is only on 2050 and low hw platform or even with 4000-5000 hw platform ?
04-13-2012 05:17 PM
Some things that will increase your commit times are high logging rates, high log forwarding to panorama, sysloging all logs, large number of rules, large number of objects. If you can reduce your logging by being more selective on exactly what you need to log, reduce the nubmer of rules and focusing on application based rules, reducing the number of objects, and reducing your log forwarding will all help reduce your commit time. I hope this helps,
~Jamie
04-15-2012 11:01 PM
Another factor that can potentially cause long commits is performing User-ID with a sizable Active Directory structure that contains thousands of User Groups. In 3.1 and 4.0 the user & group discovery is performed by the User-ID agent and the Filter Group Members setting on the agent can be used to reduce the number of user groups sent to the firewall. In 4.1 and later user & group discovery is performed by the firewall itself; the corresponding function is called Group Include List (located under Group Mapping Settings) and will need to be configured on the firewall. By only sending the groups that are actually referenced in policies on the firewall commit times can be improved, especially with very large AD environments.
04-16-2012 10:38 PM
top - 07:37:10 up 16:30, 1 user, load average: 1.20, 1.38, 0.99
Tasks: 84 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.2%us, 8.4%sy, 0.0%ni, 81.1%id, 1.0%wa, 0.2%hi, 3.1%si, 0.0%st
Mem: 1007852k total, 995864k used, 11988k free, 18224k buffers
Swap: 2008084k total, 411636k used, 1596448k free, 595788k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2610 root 20 0 384m 79m 5116 S 17 8.1 72:45.62 mgmtsrvr
2625 root 20 0 131m 63m 38m S 13 6.5 31:33.52 logrcvr
2096 root 15 -5 21680 3312 2632 S 2 0.3 24:53.92 sysd
2609 root 20 0 379m 188m 41m S 2 19.1 11:43.50 devsrvr
25219 helenio 20 0 4528 1032 840 R 1 0.1 6:33.33 top
2595 root 15 -5 0 0 0 S 0 0.0 0:29.46 kjournald
31551 helenio 20 0 22344 1128 928 S 0 0.1 0:29.93 sshd
1 root 20 0 1832 560 532 S 0 0.1 0:02.15 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.01 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.20 migration/0
4 root 15 -5 0 0 0 S 0 0.0 0:00.01 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:00.06 migration/1
6 root 15 -5 0 0 0 S 0 0.0 0:00.09 ksoftirqd/1
7 root 15 -5 0 0 0 S 0 0.0 0:00.02 events/0
8 root 15 -5 0 0 0 S 0 0.0 0:00.87 events/1
9 root 15 -5 0 0 0 S 0 0.0 0:00.02 khelper
57 root 15 -5 0 0 0 S 0 0.0 0:06.22 kblockd/0
58 root 15 -5 0 0 0 S 0 0.0 0:00.54 kblockd/1
61 root 15 -5 0 0 0 S 0 0.0 0:00.00 kseriod
65 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata/0
66 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata/1
67 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata_aux
73 root 15 -5 0 0 0 S 0 0.0 0:00.00 khubd
98 root 15 -5 0 0 0 S 0 0.0 2:32.30 kswapd0
99 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/0
100 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/1
101 root 15 -5 0 0 0 S 0 0.0 0:00.00 nfsiod
671 root 15 -5 0 0 0 S 0 0.0 0:00.00 scsi_eh_0
673 root 15 -5 0 0 0 S 0 0.0 0:00.00 scsi_eh_1
692 root 15 -5 0 0 0 S 0 0.0 0:00.36 mtdblockd
708 root 15 -5 0 0 0 S 0 0.0 0:00.00 rpciod/0
709 root 15 -5 0 0 0 S 0 0.0 0:00.00 rpciod/1
741 root 15 -5 0 0 0 S 0 0.0 0:04.64 kjournald
794 root 16 -4 2004 384 380 S 0 0.0 0:00.80 udevd
1619 root 15 -5 0 0 0 S 0 0.0 0:06.52 kjournald
1620 root 15 -5 0 0 0 S 0 0.0 0:00.00 kjournald
1895 root 20 0 2004 632 588 S 0 0.1 0:00.10 syslogd
1898 root 20 0 1888 332 328 S 0 0.0 0:00.01 klogd
1906 rpc 20 0 2080 496 492 S 0 0.0 0:00.01 portmap
1924 root 20 0 2112 668 664 S 0 0.1 0:00.06 rpc.statd
1974 root 20 0 6700 612 608 S 0 0.1 0:00.02 sshd
2003 root 20 0 6700 592 588 S 0 0.1 0:00.00 sshd
2012 root 20 0 3276 624 620 S 0 0.1 0:00.02 xinetd
2035 root 15 -5 0 0 0 S 0 0.0 0:00.00 lockd
2036 root 15 -5 0 0 0 S 0 0.0 0:05.05 nfsd
2037 root 15 -5 0 0 0 S 0 0.0 0:04.40 nfsd
2038 root 15 -5 0 0 0 S 0 0.0 0:03.14 nfsd
2039 root 15 -5 0 0 0 S 0 0.0 0:06.24 nfsd
2040 root 15 -5 0 0 0 S 0 0.0 0:03.43 nfsd
2041 root 15 -5 0 0 0 S 0 0.0 0:02.86 nfsd
2042 root 15 -5 0 0 0 S 0 0.0 0:05.15 nfsd
2043 root 15 -5 0 0 0 S 0 0.0 0:06.76 nfsd
2046 root 20 0 2356 668 576 S 0 0.1 0:00.11 rpc.mountd
2078 root 0 -20 53616 6204 3300 S 0 0.6 0:50.09 masterd_core
05-01-2012 12:14 PM
Hi,
The commit generally depends how big your configuration is. I would not feel comfortable asking you to upgrade if you have no issues on 3.1.10.
Looking at your show system resources your management server and dev server seems to be healthy too.
Thanks,
Syed Hasnain
05-08-2012 10:07 AM
A linux admin would not agree to say 400MB of swap is healthy.
Btw I usually get 7-12 minutes commit times on my PA-500 even when it's idling during night times. This is loooooong.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
