Date: Sun, 12 Oct 2003 13:30:45 -0700
From: Josh Berkus [EMAIL PROTECTED]
To: Nick Barr [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: go for a script! / ex: PostgreSQL vs. MySQL
Message-ID: [EMAIL PROTECTED]
This would be parameters such as the block size and a few other
Ivan,
There was some talk, either on this list or freebsd-performance about
setting the default block size for PostgreSQL running on FreeBSD to be 16k
because of performance reasons. That is: *default* for the port, user is
not asked. So an automagical method to scale non-default block sizes
Josh Berkus [EMAIL PROTECTED] writes:
Unless there's a way to find it in the compiled source?
See pg_controldata.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
This would be parameters such as the block size and a few
other compile time parameters. If we can get to some of these
read-only parameters than that would make this step easier,
certainly for the new recruits amongst us.
Actually, from my perspective, we shouldn't bother with
SC == Sean Chittenden [EMAIL PROTECTED] writes:
echo effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))
I've used it for my dedicated servers. Is this calculation correct?
SC Yes, or it's real close at least. vfs.hibufspace is the amount of
SC kernel space that's used for
On Monday 13 October 2003 19:34, Vivek Khera wrote:
SC == Sean Chittenden [EMAIL PROTECTED] writes:
echo effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))
I've used it for my dedicated servers. Is this calculation correct?
SC Yes, or it's real close at least.
echo effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))
I've used it for my dedicated servers. Is this calculation correct?
SC Yes, or it's real close at least. vfs.hibufspace is the amount
of SC kernel space that's used for caching IO operations (minus the
I'm just
PostgreSQL requires some more shared memory to cache some
tables, x Mb, do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
Note that this still requires a kernel recompile on FreeBSD :(
Not our fault, now is it? This would mean that we wouldn't be
JB == Josh Berkus [EMAIL PROTECTED] writes:
JB Chris,
PostgreSQL requires some more shared memory to cache some tables, x Mb,
do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
Note that this still requires a kernel recompile on FreeBSD :(
JB Not our
CK == Christopher Kings-Lynne [EMAIL PROTECTED] writes:
If shmmax and shmmall are too small, then:
PostgreSQL requires some more shared memory to cache some tables, x
Mb, do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
CK Note that this still requires a kernel
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Vivek Khera) would write:
JB == Josh Berkus [EMAIL PROTECTED] writes:
JB Chris,
PostgreSQL requires some more shared memory to cache some tables, x Mb,
do you want to increase your OS kernel parameters?
Tweak shmmax and
Sean Chittenden [EMAIL PROTECTED] writes:
Every few months one of the uber core BSD hackers threatens to rewrite
that part of PG because high up in the BSD camp, it's common belief
that shm* is a source of performance loss for PostgreSQL.
They're full of it. RAM is RAM, no? Once you've got
If shmmax and shmmall are too small, then:
PostgreSQL requires some more shared memory to cache some tables, x
Mb, do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
CK Note that this still requires a kernel recompile on FreeBSD :(
According to whom? sysctl is your
Yes, indeed, sysctl can tweak these values fairly adequately.
Now, numbers of semaphors are not as readily tweaked; I wound up
limited, the other day, when I tried setting values for...
kern.ipc.semmns
kern.ipc.semmni
Same. Maybe that was the option I was thinking was read-only:
houston#
Nick,
I reckon do a system scan first, and parse the current PostgreSQL conf
file to figure out what the settings are. Also back it up with a date
and time appended to the end to make sure there is a backup before
overwriting the real conf file. Then a bunch of questions. What sort of
Chris,
PostgreSQL requires some more shared memory to cache some tables, x Mb,
do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
Note that this still requires a kernel recompile on FreeBSD :(
Not our fault, now is it? This would mean that we wouldn't be
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
I think Sean(?) mentioned this one for FreeBSD (Bash code):
sh, not bash. :)
echo effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))
I've used it for my dedicated servers.
On Sat, 2003-10-11 at 05:22, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Rod Taylor [EMAIL PROTECTED] writes:
Would anyone object to a patch that exports the blocksize via a
readonly GUC? Too many tunables are page dependant, which is
infuriating when copying configs from DB to
If shmmax and shmmall are too small, then:
PostgreSQL requires some more shared memory to cache some tables, x Mb,
do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
Note that this still requires a kernel recompile on FreeBSD :(
Chris
Heya Guys n Gals,
Having been following the thread on go for a script! / ex: PostgreSQL vs.
MySQL. I thought I would throw something together in Perl. My current issue
is that I only have access to a RH Linux box and so cannot make it
cross-platform on my own :-(. Anyhow please find it attached.
- Original Message -
From: Nick Barr [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 10, 2003 1:35 PM
Subject: go for a script! / ex: PostgreSQL vs. MySQL
I will also post it on me website and as I develop it further new
versions
will appear there
Nick,
Having been following the thread on go for a script! / ex: PostgreSQL vs.
MySQL. I thought I would throw something together in Perl.
Cool! Would you be willing to work with me so that I can inject some of my
knowledge of .conf tuning?
--
Josh Berkus
Aglio Database Solutions
San
SC == Sean Chittenden [EMAIL PROTECTED] writes:
SC patches to extract info from their OS so that initdb can make useful
SC decisions. Or, lastly, does anyone think that this should be in a
SC different, external program? -sc
Well, there should definitely be a way to run a get current best
NB == Nick Barr [EMAIL PROTECTED] writes:
NB So far:
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
Please take into account the blocksize compiled into PG, too...
--
Vivek,
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
Please take into account the blocksize compiled into PG, too...
We can;t change the blocksize in a script that only does the .conf file. Or
are you suggesting something else?
--
JB == Josh Berkus [EMAIL PROTECTED] writes:
JB Vivek,
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
Please take into account the blocksize compiled into PG, too...
JB We can;t change the blocksize in a script that only does the .conf
NB So far:
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
Please take into account the blocksize compiled into PG, too...
Would anyone object to a patch that exports the blocksize via a
readonly GUC? Too many tunables are page
Sean Chittenden wrote:
NB So far:
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
Please take into account the blocksize compiled into PG, too...
Would anyone object to a patch that exports the blocksize via a
readonly GUC?
On Fri, 2003-10-10 at 18:59, Sean Chittenden wrote:
NB So far:
NB shared_buffers = 1/16th of total memory
NB effective_cache_size = 80% of the supposed kernel cache.
Please take into account the blocksize compiled into PG, too...
Would anyone object to a patch that exports the
Hi guys,
I followed the discussion and here are my 0.2$:
I think instead of thinking about where to put the
information about tuning, someone should provide a
pgsql-autotune. Maybe even a shell script would do the
trick.
It's not so hard to find out, how much memory is installed,
and IMHO
On 09/10/2003 09:29 Oliver Scheit wrote:
Hi guys,
I followed the discussion and here are my 0.2$:
I think instead of thinking about where to put the
information about tuning, someone should provide a
pgsql-autotune. Maybe even a shell script would do the
trick.
It's not so hard to find out, how
Yeah, I had similar thought to Oliver's and suspected that this would be
the answer.
Also, while it's not too hard to do this for a single platform, it gets
complecated once you start looking at different ones.
Josh, let me know when you're ready to do this. I'll try to help,
although my perl's
32 matches
Mail list logo
