Re[2]: Memory requirements for web-project - Mailing list pgsql-general
From | Boris |
---|---|
Subject | Re[2]: Memory requirements for web-project |
Date | |
Msg-id | 677866831.20010204181307@x-itec.de Whole thread Raw |
In response to | Re: Memory requirements for web-project (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Responses |
Re: Re[2]: Memory requirements for web-project
Re: Re[2]: Memory requirements for web-project |
List | pgsql-general |
Hello Lincoln, Sunday, February 04, 2001, 5:51:37 PM, you wrote: LY> At 05:10 PM 2/4/01 +0100, Boris wrote: >>160.000 hits are wanted, so I calculate 160.000 div 24 = approx 6666 >>Hits a hour, div 60 = 111 Hits a minute, = 1,85 Hits per secound. >> >>lets round it up to 2 hits per secound. So I calculate now >>2 hits per second * 3 seconds for a client >>= 6 processes at the same time, >> >>is that correct? LY> My guess is that your hits are likely to bunch up at certain times, rather LY> than be spread out evenly (90% of the people behave similarly 90% of the LY> time). So you might wish to multiply by 5 or 10 (or whatever you pluck from LY> the air ;) ) to cater for peak load. LY> Why are you saying it takes 3 seconds for a client? If it's because the LY> client is slow, you can do something about that, but if it's because your LY> query takes 3 seconds then maybe some people here could help with your query. >>If so, how much is the memory requiremend? I have seen with "TOP" that >>pgsql requires 5000kb for a request, but it is used per client (new LY> processes LY> The minimum size varies depending on what platform it's running on. LY> The max seems to vaguely depend on the size of the result set. But usually LY> most of the mem is reclaimed after the query is finished, at least on my LY> system. LY> Just do some tests with your bigger queries. LY> I'd say go for 512MB RAM. LY> Coz, usually you can't add RAM during peak load, and if you can, it usually LY> means you have hardware where 1GB or more is minimum anyway ;). LY> And you might be able to stick half on another server (web+app) if LY> desperate :). LY> Cheerio, LY> Link. Hello Lincoln, Sunday, February 04, 2001, 5:51:37 PM, you wrote: LY> At 05:10 PM 2/4/01 +0100, Boris wrote: >>160.000 hits are wanted, so I calculate 160.000 div 24 = approx 6666 >>Hits a hour, div 60 = 111 Hits a minute, = 1,85 Hits per secound. >> >>lets round it up to 2 hits per secound. So I calculate now >>2 hits per second * 3 seconds for a client >>= 6 processes at the same time, >> >>is that correct? LY> My guess is that your hits are likely to bunch up at certain times, rather LY> than be spread out evenly (90% of the people behave similarly 90% of the LY> time). So you might wish to multiply by 5 or 10 (or whatever you pluck from LY> the air ;) ) to cater for peak load. Ah, very interesting, yes - I forgot! LY> Why are you saying it takes 3 seconds for a client? If it's because the No its a server problem, has nothing to do with the database -) LY> The minimum size varies depending on what platform it's running on. Aha, interesting. LY> The max seems to vaguely depend on the size of the result set. But usually LY> most of the mem is reclaimed after the query is finished, at least on my LY> system. Interesting to know. LY> Just do some tests with your bigger queries. Ok, good idea. LY> I'd say go for 512MB RAM. That sounds good, the only question left is the memory requiremend of apache per client, i do not completely understand the spawning things with Apache. On high load there are alway minimum 10 processes left, but where is the limit? Interesting thing. LY> Coz, usually you can't add RAM during peak load, and if you can, it usually LY> means you have hardware where 1GB or more is minimum anyway ;). LY> And you might be able to stick half on another server (web+app) if LY> desperate :). ok. LY> Cheerio, LY> Link. Thanks, that helped a lot! -- Boris www.x-itec.de -- Boris [MCSE, CNA] ................................................................... X-ITEC : Consulting * Programming * Net-Security * Crypto-Research ........: [PRIVATE ADDRESS:] : Boris Köster eMail koester@x-itec.de http://www.x-itec.de : Grüne 33-57368 Lennestadt Germany Tel: +49 (0)2721 989400 : 101 PERFECTION - SECURITY - STABILITY - FUNCTIONALITY ........:.......................................................... Everything I am writing is (c) by Boris Köster and may not be rewritten or distributed in any way without my permission.
pgsql-general by date: