On Sep 24, 2013, at 11:27 AM, Andrew Deason <adea...@sinenomine.net> wrote: > Logging it is definitely helpful and OK, though logging from rx is not > great. Are you currently using existing mechanisms by just printing to > stderr, or some new mechanism for logging from rx? I'm just using dpf() in the prototype; of course I'd need something better for any upstream version.
>> 2) Volume releases suffer from poor performance and occasionally fail >> with timeouts. >> - root cause was heavier-than-normal vlserver load (perhaps caused >> by disk performance slowdowns); this starved LWP IOMGR, which in >> turn prevented LWP rx_Listener from being dispatched (priority >> inversion), leading to a grossly delayed rxevent queue. > > I'm not sure if I'm mistaken as to what this is about, or if I just find > this phrasing really confusing. I thought the issue here was just that > ubik proceses (such as vlserver) use plain read() and write() calls to > read and write from disk; so if they take a while, all LWPs will freeze > because we cannot preempt the LWP waiting on i/o. Is that correct? Yes, that's correct; both cores for the LWP case showed we were waiting for an (LWP-synchronous) disk read to complete. I think we are saying the same thing, but it sounds clearer the way you say it! But it's not _just_ that the disk IO is synchronous; the site reported that disk IO was indeed suffering from poor performance at the time. -- Mark Vitale mvit...@sinenomine.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
