On Mon 24-12-12 14:38:50, azurIt wrote: > >OK, good to hear and fingers crossed. I will try to get back to the > >original problem and a better solution sometimes early next year when > >all the things settle a bit. > > > Btw, i noticed one more thing when problem is happening (=when any > cgroup is stucked), i fogot to mention it before, sorry :( . It's > related to HDDs, something is slowing them down in a strange way. All > services are working normally and i really cannot notice any slowness, > the only thing which i noticed is affeceted is our backup software ( > www.Bacula.org ). When problem occurs at night, so it's happening when > backup is running, backup is extremely slow and usually don't finish > until i kill processes inside affected cgroup (=until i resolve the > problem). Backup software is NOT doing big HDD bandwidth BUT it's > doing quite huge number of disk operations (it needs to stat every > file and directory). I believe that only speed of disk operations are > affected and are very slow. I would bet that this is caused by the blocked proceses in memcg oom handler which hold i_mutex and the backup process wants to access the same inode with an operation which requires the lock. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
