Connection Pooling is not going to greatly impact the log insertion rate. There will be a re-use of connections from clients so you eliminate some of the "connection accepted" chatter that you have probably noticed in the logs. However, queries on that connection may well still generate messages, and the connection messages (also from replication) will continue to show up, just at a lesser rate. There will also be plenty of other messaging in there.
Log rotation and deletion (of old logs) is definitely what you want if the size is what concerns you. How to rotate mongo logs is covered here:
Then tailor this with a cron job (or other periodic implementation) to archive/delete the older logs as you go along. How long to keep exactly is up to you, my general recommendation would be to keep a week at a minimum. Often that is the minimum to compare usage patterns when investigating an issue, but the actual retention is completely up to you.
If your log is large, you probably need to rotate it.
Connection pooling would be helpful for performance, but you state the problem is log file size. so address log file size.
Connection Pooling is not going to greatly impact the log insertion rate. There will be a re-use of connections from clients so you eliminate some of the "connection accepted" chatter that you have probably noticed in the logs. However, queries on that connection may well still generate messages, and the connection messages (also from replication) will continue to show up, just at a lesser rate. There will also be plenty of other messaging in there.
Log rotation and deletion (of old logs) is definitely what you want if the size is what concerns you. How to rotate mongo logs is covered here:
http://www.mongodb.org/display/DOCS/Logging#Logging-Rotatingthelogfiles
Then tailor this with a cron job (or other periodic implementation) to archive/delete the older logs as you go along. How long to keep exactly is up to you, my general recommendation would be to keep a week at a minimum. Often that is the minimum to compare usage patterns when investigating an issue, but the actual retention is completely up to you.