We're having issues with policyd with regards to performance. We have
about 40,000 users we process mail for. We're hosting all our SMTP
services on Amazon Web Services and using an RDS Postgresql database to
store data.
What we're seeing is around 1200 - 1800 concurrent connections to the
database during business hours. This seems quite high to me.
We've increased the instance size of our database servers to 8 core,
60GB instances and done some buffer tuning on the database.
We're running an instance of cbpolicyd on our postfix servers, on 8
core, 16GB instances. Initially, the postfix instances were small 2 core
instances and policyd ran on separate 4 core instances but performance
was so pitiful that we moved policyd onto the postfix instance and
increased the instance size to compensate.
With the 8 core postfix/policyd instances, we're running about 16 - 24
instances during peak hours. When we were running only postfix on our 2
core instances, we never ran more than 4 concurrently (and that was
mostly out of an abundance of caution).
We've adjusted both the number and duration of policy connections in
postfix with mixed results.
Before I post any detailed configuration information, can anyone offer
any baseline performance metrics for their policyd installations?
We only have 15 policies in place right now while we're testing but this
will quickly grow once we go into production.
We have 201000 rows in the policy_group_members table.
I'm concerned that, even with this small amount of data, performance
will only get worse once more data and policies are introduced.
Either we're doing something terribly wrong or policyd is a beast. I'm
hoping it's the former.
If anyone can offer any advice, insight I'd be very interested in
hearing them.
_______________________________________________
Users mailing list
Users@lists.policyd.org
http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
