[postgis-users] Performance and memory problems

Andrea Aime andrea.aime at aliceposta.it
Thu Dec 4 07:32:47 PST 2003


strk wrote:

 > andrea.aime wrote:
 >
 >>strk wrote:
 >>
 >>
 >>>What C++ compiler do you have (name/version) ?
 >>>
 >>
 >>Libraries are:
 >>
 >>gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)
 >>glibc version 2.3.1
 >>libstc++5-3.2.2
 >
 >
 > You can try disabling the memory cache feature of libstdc++ by
 > exporting GLIBCPP_FORCE_NEW=1 before starting the postgresql
 > postmaster. This might save some memory.

Does not work :-(

 > I've had problems with 3.2.2 also try to upgrading to 3.3.2.

Updating the compiler is a bit out of my reach, I don't have enough
time to fiddle with gcc removal and installation from sources.
I will try at home where I have a mdk 9.2 which uses 3.3.1.

 > Ask on the pgsql-hackers mailing list about postmaster
 > stack trace (and please let me know).
 >

Will do. I've also noted something strange: before maxing out memory
vmstat reports that the cpu is used almost 100% by system tasks, not
user ones... look at this "vmstat 1" output:

(A): here I started the query
(B): here it starts spinning like mad in the system area
(C): boom

0  0      0  69464  35592 117008    0    0     0   120  117   101  0  2 98  0
  3  0      0  65148  35592 117700    0    0     0     0  103    90 58  8 34  0 (A)
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
  1  0      0  64672  35592 117836    0    0     0     0  101    61 69 31  0  0
  2  0      0  66832  35592 117972    0    0     0     0  101    59 50 50  0  0
  1  0      0  66960  35592 118092    0    0     0     0  101    62 63 37  0  0
  2  0      0  66020  35592 118228    0    0     0   200  128    75 61 39  0  0
  1  0      0  65032  35592 118308    0    0     0     0  102    63 55 45  0  0
  1  0      0  66292  35592 118444    0    0     0     0  101    68 54 46  0  0
  1  0      0  65444  35592 118564    0    0     0     0  101    72 72 28  0  0
  1  0      0  66444  35596 118672    0    0     4     0  102    73 46 52  2  0
  1  0      0  65144  35596 118880    0    0     0   180  127    88 54 46  0  0
  1  0      0  66176  35596 119048    0    0     0     0  102    68 59 41  0  0
  1  0      0  64264  35596 119320    0    0     0     0  102    74 77 23  0  0
  1  0      0  64076  35596 119432    0    0     0     0  102    74 50 50  0  0
  1  0      0  62732  35596 119536    0    0     0     0  101    79 84 16  0  0
  2  0      0  62596  35596 119536    0    0     0   228  119    83 89 11  0  0
  1  0      0  62532  35596 119536    0    0     0     0  101    75 10 90  0  0
  1  0      0  62520  35596 119536    0    0     0     0  101    77  5 95  0  0 (B)
  1  0      0  61328  35596 119536    0    0     0     0  101    80  5 95  0  0
  1  0      0  61496  35596 119536    0    0     0     0  101    76  4 96  0  0
  1  0      0  62508  35596 119536    0    0     0    24  105    82 10 90  0  0
  1  0      0  60296  35596 119536    0    0     0     0  101    71  5 95  0  0
  1  0      0  60772  35596 119536    0    0     0     0  101    66  3 97  0  0
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
  1  0      0  60812  35596 119536    0    0     0     0  101    70  6 94  0  0
  1  0      0  61604  35596 119536    0    0     0     0  101    70  2 98  0  0
  2  0      0  65208  35596 119744    0    0     0    28  106    79 21 79  0  0
  1  0      0  64224  35596 119864    0    0     0     0  101    68 91  9  0  0
  1  0      0  64548  35596 120012    0    0     0     0  101    66 71 29  0  0
  0  0      0  69716  35596 117268    0    0    16  1548  172   123 15 27 58  0 (C)
  0  0      0  69716  35596 117268    0    0     0     0  101    64  0  0 100  0
  0  0      0  70140  35596 117268    0    0     0   136  123   116  0  1 99  0

I wonder why it is starting to behave like this at B since the postmaster process
never uses more than 20 MB on the RSS column of the "top" output...

Andrea





More information about the postgis-users mailing list