Re: [PERFORM] Check Pointer
--On 30. Mai 2013 18:15:04 +0530 itishree sukla itishree.su...@gmail.com wrote: Thanks for the quick response. Below is the out put of Top Commnd. 3971 postgres 20 0 8048m 303m 301m S 0 0.9 0:04.34 /usr/lib/postgresql/9.2/bin/postgres -D /var/lib/postgresql/9.2/main -c config_file=/etc/postgre 3972 postgres 20 0 66828 1820 708 S 0 0.0 1:36.37 postgres: logger process 3974 postgres 20 0 8054m 7.6g 7.6g S 0 24.1 0:56.59 postgres: checkpointer process On Linux i often find the pmap utility a far better tool to get an idea what a process actually consumes of memory. The output can be large sometimes, but it's more fine grained. -- Thanks Bernd -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] DRBD and Postgres: how to improve the perfomance?
--On Samstag, September 08, 2007 12:39:37 -0400 Tom Lane [EMAIL PROTECTED] wrote: However, it seems like the point here is not so much can you recover your data as what a commit means. Do you want a commit reported to the client to mean the data is safely down to disk in both places, or only one? Yeah, that's what i meant to say. DRBD provides a handful other tweaks besides changing the sync protocol, i'd start with them first. You can get back experimenting with the sync protocol if there are still performance issues then. I don't hesitate changing to B as long as I'm aware that it changed semantics and I can deal with them. -- Thanks Bernd ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] DRBD and Postgres: how to improve the perfomance?
--On Freitag, September 07, 2007 20:00:16 +0100 Simon Riggs [EMAIL PROTECTED] wrote: On Fri, 2007-09-07 at 11:37 +0200, Maila Fatticcioni wrote: protocol C; Try protocol B instead. But that would have an impact on transaction safety, wouldn't it? It will return immediately after reaching the remote buffer cache and you can't be sure your data hits the remote disk. It's a while ago i've played with such a setup, but it could be worth to play around with max_buffers, al-extends, snd-bufsize. Oh and i think Maila's 'rate' setting is too high: i've found rate settings counterproductive when set too high (try a value slightly above your max bandwidth of your connection). But i second Heikki, you should take care on your disk setup as well. -- Thanks Bernd ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PERFORM] Partitioning
On Wed, 10 Jan 2007 15:30:16 -0600, Scott Marlowe [EMAIL PROTECTED] wrote: [...] And I don't think the mysql partition supports tablespaces either. MySQL supports distributing partitions over multiple disks via the SUBPARTITION clause [1]. I leave it to you, wether their syntax is cleaner, more powerful or easier or ;) Bernd [1] http://dev.mysql.com/doc/refman/5.1/en/partitioning-subpartitions.html ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] Partitioning
On Thu, 11 Jan 2007 08:18:39 -0600, Adam Rich [EMAIL PROTECTED] wrote: Subpartitions are just a way to break (parent) partitions up into smaller pieces. Those of course can be moved to other disks just like the main partitions. Ah, didn't know that (i just wondered why i need a subpartition to change the location of a partition). Thanks for your clarification... Bernd ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
