Ballpark number of clients per server for push & pull modes?
Hi All,
Just wondering if there were any ballpark figures people use, or Symantec recommend for the point at which you should switch from the default push mode to pull? Have read that push is only suitable for small to mid sized networks, but nothing really qualifying anything like a ballpark number of clients per server or what exact signs to look for if you suspect you are reaching that threshold. Have a small network running SEP MR4 MP4 with less than 100 clients, and the SEP Management server is experiencing issues with LUCALLBACKPROXY consuming close to 100% CPU from time to time. Just wondering if switching from push to pull will stop LUCALLBACKPROXY from consuming all the CPU, or if it will just reduce the frequency that this happens?
Comments
100% CPU from time to time.
100% CPU from time to time. Just wondering if switching from push to pull will stop LUCALLBACKPROXY from consuming all the CPU,
I understand this will not impact the LUCALLBACKPROXY, however the request to SEPM will be reduced if you opt for pull mode as there will not be continous connection with the SEPM box.
As i know if DB is sybase it goes to 5000 clients, if SQL it is around 50000 clients
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Scaling How many clients can
Scaling
How many clients can I manage with a single Symantec Endpoint Protection Manager?
Symantec Endpoint Protection Manager can manage 50,000 clients as long as network resources are available.
How many clients can I manage if I use the embedded database?
Symantec recommends that you can use the embedded database for up to 5,000 clients. If you have more clients, you should use a stand alone database.
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007071909500548
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Thanks for the replies. My
Thanks for the replies. My question was more around when to start using the pull mode over push mode rather than the maximum number of clients SEP manager can support. Ultimately it doesn't sound like it is going to fix my problem of LUCALLBACKPROXY taking up all the CPU anyway, so I'll keep reading the admin guide and see what I can find. Thanks again.
Pull mode is better for any
Pull mode is better for any architecture of SEPM since there will less resource utilization on the SEPM.
There is no official figure ( I assume) it's totally on the environmental and network architecture.
You may set the heartbeat to 30 minutes .
LUCALLBACKPROXY--> is the process associated with the LiveUpdate, since the SEPM or the SEP client on the SEPM has called Liveupdate, the heartbeat does not impact.
You may check the Liveupdate folder and content folder within SEPM if the definitions are downloaded. If there are corrupted files you may manually download the jdb file to update the SEPM.
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
ok here you go , upgrade to
ok here you go , upgrade to MR4 MP2 ( suggest to move to RU5), and see if that helps.
http://service1.symantec.com/support/ent-security.nsf/docid/2009031709563248
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Thanks Pete. That has
Thanks Pete. That has answered my question about LUCALLBACKPROXY at any rate. If it is a liveupdate process, then push/pull delivery is not going to effect it as far as I can see. We have already upgraded to MR4 MP2 for this exact reason, and will be looking at moving to RU5 in the next week or so.
I'll look at changing the Liveupdate schedule from continuous to scheduled times to see if that can at least reduce the impact.
ok, definetly scheduled one
ok, definetly scheduled one would be a better option , as Symantec posts 3 updates each date, hence scheduling Live update every 4- 6 hours will help
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Would you like to reply?
Login or Register to post your comment.