Core Data Intermittently Blocked Over AFP?
Core Data Intermittently Blocked Over AFP?
- Subject: Core Data Intermittently Blocked Over AFP?
- From: Steve Steinitz <email@hidden>
- Date: Wed, 09 Mar 2011 09:28:41 +1100
Hello,
Our Core Data App Runs on seven machines, five of them pretty
active, all sharing a store on a Network drive over AFP.
Previously I've accepted constructive criticism of that
architecture and ideas on alternative architectures, but in this
thread I'd like to focus on one particular anomaly. Namely:
The machines appear to become "blocked", i.e. fetches that
usually take a few hundredths of a second begin take 15 seconds
or more. It happens after another machine saves to the
database. Only relaunching the App fixes it - until another
machine saves.
There appears to be no intermediate slowness: the fetches take
either well less than a second or, oddly, almost exactly 17 or
28 seconds, sometimes 33 seconds.
It may be relevant that he slowness usually appears on one
complex entity: Sale. Sales have payments, lineItems, bikes,
customer, employee, risk log entries. Bikes and lineItems have
products which have models. Models have categories and brands,
brands have suppliers. Core Data's built-in prefetch path can't
follow relationships after a to-many relationship and I haven't
hand-coded those prefetches (per the old 10.4 prefetch
workaround), so none of the objects related beyond lineItems and
bikes get prefetched. The problem occurs with or without prefetching.
The problem occurs regardless of the network drive: Synology,
Thecus, Mac Mini.
This problem originally reared its head with Mac OS X 10.6.
Then, the slowness was more dramatic: fetch times would
sometimes increase to 3 minutes, a couple of times I saw 30 minutes.
At that time Ben Trumbull came to the rescue. After examining
shark and other lower-level instrument output, he suggested that
I "wave a dead chicken over the problem": increase the sqlite
page_size from the default of 1024 to the maximum of 16384.
That immediately solved the problem and all was well for six
months. Then, the problem appeared again and I determined
experimentally that setting the page_size to 4096 fixed it.
Last Friday, after rebuilding some indexes, the problem appeared
again. Fetches of Sale take either less than 0.1 seconds or 15
- 30 seconds. Again, it sticks to a value: if it starts out at
25 seconds, it stays 25 seconds.
No page_size setting fixes it. I've tried a number of network
tweaks etc. I also noticed that if I artificially produced a
scenario where Sale was never queried, the problem eventually
appeared on simpler entities.
My working hypothesis (based on Ben's musings) is that AFP
begins to "starve" or lower the priority of clients which
haven't written for a while, and that that is only apparent in
a complex fetch with many faults firing.
Anyway, before I raise a bug report for an intermittent problem
on an architecture that's now more or less frowned upon, I'm
open for any on-topic comments.
Cheers,
Steve
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden