Hi, Mohan2005 schrieb: > Hello > > Thaks. We will enable loggin to find this, but since its a production setup > will it affect performance ?
The numbers suggest, that you've got 210.000 * 12(instances) / 21 (days) = 120.000 requests/day So depending on the time distribution, this should boild down to about 5 requests/second peak load. If your local disks are modern and there is enough file system space for the log, enabling debug log level should be OK. But: rethinking my suggestion, I think the needed info will *not* be in the logs. > > This is a set of stats. Apache was running for 3 weeks. (Hope this is clear) > mod_jk 1.2.18 with Busyness and sticky sessions (all nodes are identicical). > > > Name Type jvmRoute Host Addr Stat D F M > V Acc Err Wr Rd Busy Max RR Cd > server1_1 ajp13 server1_1 172.16.1.138:8009 172.16.1.138:8009 OK 0 1 1 > 1 181792 22 152M 16G 1 39 WwwGroupServer1Com > server2_1 ajp13 server2_1 172.16.1.139:8009 172.16.1.139:8009 OK 0 1 1 > 3 218096 37 185M 18G 3 130 WwwGroupServer2Com > server3_1 ajp13 server3_1 172.16.1.135:8009 172.16.1.135:8009 OK 0 1 1 > 1 32348 1 29M 2.8G 0 36 WwwGroupServer3Com > server4_1 ajp13 server4_1 172.16.1.140:8009 172.16.1.140:8009 OK 0 1 1 > 1 192940 23 164M 16G 0 27 WwwGroupServer4Com > server2_2 ajp13 server2_2 172.16.1.139:18009 172.16.1.139:18009 OK 0 1 1 > 1 209807 33 178M 17G 1 38 WwwGroupServer2Com > server3_2 ajp13 server3_2 172.16.1.135:18009 172.16.1.135:18009 OK 0 1 1 > 1 208006 67 174M 18G 1 60 WwwGroupServer3Com > server1_2 ajp13 server1_2 172.16.1.138:18009 172.16.1.138:18009 OK 0 1 1 > 1 148020 17 126M 13G 1 32 WwwGroupServer1Com > server4_2 ajp13 server4_2 172.16.1.140:18009 172.16.1.140:18009 OK 0 1 1 > 2 203780 16 174M 17G 2 43 WwwGroupServer4Com > server1_3 ajp13 server1_3 172.16.1.138:38009 172.16.1.138:38009 OK 0 1 1 > 0 178381 11 148M 15G 0 42 WwwGroupServer1Com > server2_3 ajp13 server2_3 172.16.1.139:38009 172.16.1.139:38009 OK 0 1 1 > 0 196352 11 162M 16G 0 23 WwwGroupServer2Com > server3_3 ajp13 server3_3 172.16.1.135:38009 172.16.1.135:38009 OK 0 1 1 > 5 184697 10 154M 16G 5 65 WwwGroupServer3Com > server4_3 ajp13 server4_3 172.16.1.140:38009 172.16.1.140:38009 OK 0 1 1 > 0 175744 34 145M 14G 0 28 WwwGroupServer4Com There are obviously two workers, with uneven numbers: server3_1 and to some minor degree server1_2. Number 3_1 really looks suspicious. Maybe it has been in error status/down/stopped/disabled for a longer time? Remember: method "B" tries to keep "Busy" even. This could mean, that the workers get different numbers of requests over a longer time. Nevertheless I would not expect such huge differences as with 3_1. All other numbers are plausible for "B" with stickyness. The differences in Busy numbers (0 to 5) could be related to stickyness. If you are using URL encoding you can have a look into the apache access logs to determine the rate of requests going to tomcat, that carry session info. If you are using Cookies, you can log the incoming "Cookie" header in the log (check docs for mod_log_config for the syntax for incoming headers) and do the same check. If you've got relatively few requests without session, then think of it as first feeding most requests into their sticky slot and then adding only a few to the remaining slots with lowest (usually 0 or 1) busyness. > In workers.properties... > worker.loadbalancer.balance_workers=server1_1, server2_1, server3_1, > server4_1, server2_2, server3_2, server1_2, server4_2, server1_3, server2_3, > server3_3, server4_3 > > worker.loadbalancer.lock=P Did you have any reason for "P"? Recent versions seem to run OK with "O", which should perform better. > worker.loadbalancer.method=B > worker.loadbalancer.local_worker_only=1 The last one (local_worker_only) doesn't exist any more (and wouldn't have made sense in this situation). It gets ignored. Regards, Rainer --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
