Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I am using POST to update the delete-at time. I do have object_post_as_copy set false. (At least it's there in the config file. I didn't see a way to confirm that it's actually happening.) From your reaction it sounds like a weird thing to do. What is the usual solution to a problem like this? Store delete-at in some other db, and write my own object expirer?

I have read the general service tuning section, but it doesn't give much guidance. I'm running the object-server with 8 workers. Presumably that's enough to avoid problems caused by one object server being temporarily hung. The CPU on each server is only 50% used. Interestingly it's the container server/replicator that are consistently at the top of top output. Fairly often I see a container-replicator using 100% of one core. Is there any downside to having too many workers? I'm thinking of just giving each server 16 workers, with a concurrency of 1, and let Linux sort it out.

Does the object expirer log a delete also when an old copy of metadata is deleted? If so, that would explain the large number of deletes, and those files should be tiny so deleting them shouldn't add significant load to anything.