Subject | FB SS 2.5 SMP - clarification |
---|---|
Author | unordained |
Post date | 2012-04-20T20:49:45Z |
I realize this isn't official, but what I'm looking at is: http://
www.iblogmanager.com/download/misc/articles/fb25_architecture_comparison.pdf
For SuperServer, it lists SMP as available as long as the connections are talking
to different databases, serialized if same database. This correlates fairly well
with the official documentation. How strict is that, exactly?
Can the load for operations on a single database be shared across CPUs for
operations not *strictly* affecting said database (not actively selecting/
updating): temporary-file SORT, calling UDF's, "doing math"? That is, are the
connections synchronized only when actively touching the database file & cache,
or are they synchronized from the moment they connect to a given database file,
regardless of what they're asking to do?
Background:
I'm currently contemplating switching from 2.1 CS to 2.1 SS on an SMP server,
because of the non-shared-cache cost. The DB is metadata-heavy (but usually quite
CPU-friendly, that's not an issue), and a lot of queries currently seem to block
just at prepare time, as it loads 200 megs of metadata (it always seems like a
lot to me -- does it prepare BLR "inline"'d, multiplying the size of the code in
RAM?) into RAM for that instance. They're connection-pooled (tomcat) but DBCP
often rotates out the "already cached" db instances in favor of the "small but
dumb" ones, and then another user soon pays the cost again, which pains me
greatly. It can take 3-4 seconds to load that much metadata; also, that
accumulates quickly in a multi-user setting, and I start having swap-space
issues, which aren't helping my i/o costs. (I have a lot of tables, triggers, and
dependencies between them: a single insert can, in theory, have a ripple effect
across dozens of tables, and I understand why FB has to prepare for it.) I'm
hoping SS can help me pay that cost nearer to once per boot and, overall, perform
better. But I'm looking at 2.5, wondering if I could get *more* benefit in this
SMP environment if I moved up to 2.5 SS, also. Not necessarily immediately, but
later. I'm currently using 2.1.5-snapshot, I'll need to make sure there's a 2.5.x
with all the neat hacks "the guys" have been so kind as to make. (Thank you, your
changes have already helped me out quite a bit.)
-Philip
www.iblogmanager.com/download/misc/articles/fb25_architecture_comparison.pdf
For SuperServer, it lists SMP as available as long as the connections are talking
to different databases, serialized if same database. This correlates fairly well
with the official documentation. How strict is that, exactly?
Can the load for operations on a single database be shared across CPUs for
operations not *strictly* affecting said database (not actively selecting/
updating): temporary-file SORT, calling UDF's, "doing math"? That is, are the
connections synchronized only when actively touching the database file & cache,
or are they synchronized from the moment they connect to a given database file,
regardless of what they're asking to do?
Background:
I'm currently contemplating switching from 2.1 CS to 2.1 SS on an SMP server,
because of the non-shared-cache cost. The DB is metadata-heavy (but usually quite
CPU-friendly, that's not an issue), and a lot of queries currently seem to block
just at prepare time, as it loads 200 megs of metadata (it always seems like a
lot to me -- does it prepare BLR "inline"'d, multiplying the size of the code in
RAM?) into RAM for that instance. They're connection-pooled (tomcat) but DBCP
often rotates out the "already cached" db instances in favor of the "small but
dumb" ones, and then another user soon pays the cost again, which pains me
greatly. It can take 3-4 seconds to load that much metadata; also, that
accumulates quickly in a multi-user setting, and I start having swap-space
issues, which aren't helping my i/o costs. (I have a lot of tables, triggers, and
dependencies between them: a single insert can, in theory, have a ripple effect
across dozens of tables, and I understand why FB has to prepare for it.) I'm
hoping SS can help me pay that cost nearer to once per boot and, overall, perform
better. But I'm looking at 2.5, wondering if I could get *more* benefit in this
SMP environment if I moved up to 2.5 SS, also. Not necessarily immediately, but
later. I'm currently using 2.1.5-snapshot, I'll need to make sure there's a 2.5.x
with all the neat hacks "the guys" have been so kind as to make. (Thank you, your
changes have already helped me out quite a bit.)
-Philip