On 10/27/06, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > r b   swpd  free   buff    cache si so bi    bo   in   cs us sy id wa
> > 1 0 345732 29328 770980 12947212  0  0 20 16552 1223 3677 12  2 85  1
> > 1 0 345732 29840 770520 12946924  0  0 20 29244 1283 2955 11  2 85  1
> > 1 0 345732 32144 770560 12944436  0  0 12 16436 1204 2936 11  2 86  1
> > 1 0 345732 33744 770464 12942764  0  0 20 16460 1189 2005 10  2 86  1
> > 2 0 345732 32656 770140 12943972  0  0 16  7068 1057 3434 13  2 85  0
> > 1 0 345732 34832 770184 12941820  0  0 20  9368 1170 3120 11  2 86  1
> > 1 0 345732 36528 770228 12939804  0  0 16 32668 1297 2109 11  2 85  1
> > 1 0 345732 29304 770272 12946764  0  0 16 16428 1192 3105 12  2 85  1
> > 1 0 345732 30840 770060 12945480  0  0 20 16456 1196 3151 12  2 84  1
> > 1 0 345732 32760 769972 12943528  0  0 12 16460 1185 3103 11  2 86  1
>
> It doesn't look like there's anything else running - the runnable "r" is
> about 1.  Your "bo" blocks output rate is about 16MB/s, so divide by 3 and
> you're about in range with your 5MB/s COPY rate.  The interesting thing is
> that the I/O wait is pretty low.
>
> How many CPUs on the machine?  Can you send the result of "cat
> /proc/cpuinfo"?

iirc, he is running quad opteron 885 (8 cores), so if my math is
correct he can split up his process for an easy gain.

Are you saying that I should be able to issue multiple COPY commands
because my I/O wait is low?  I was under the impression that I am I/O
bound, so multiple simeoultaneous loads would have a detrimental
effect ...

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to