Re: postgresql 9.5 has ocuuered OOM
On Wed, Dec 20, 2017 at 9:25 AM, Andreas Kretschmer wrote: > > > Am 20.12.2017 um 16:08 schrieb mark: >> >> postgresql process used over 70% of memory and occuered OOM. >> what should I do to deal with this problem? > > > https://www.postgresql.org/docs/current/static/kernel-resources.html > 18.4.4. Linux Memory Overcommit More specifically: https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT To reiterate the basic message there, at no time should the OS think that killing big processes is OK. It is NOT. At no time should your OS be terminating big processes all on its own. Also it's far better to starve your work_mem and keep all the processes running than to ever run any out of memory. But if one does run out of memory it should only cause a problem for that one process, not the backend writer etc.
Re: Postgres HA
On Fri, Jan 5, 2018 at 12:07 PM, Azimuddin Mohammed wrote: > > Hello, > I am little confused with how HA works in postgres. Reading the article which > state as below "If the primary server fails and the standby server becomes > the new primary, and then the old primary restarts, you must have a mechanism > for informing the old primary that it is no longer the primary. This is > sometimes known as STONITH (Shoot The Other Node In The Head), which is > necessary to avoid situations where both systems think they are the primary, > which will lead to confusion and ultimately data loss. > > Many failover systems use just two systems, the primary and the standby, > connected by some kind of heartbeat mechanism to continually verify the > connectivity between the two and the viability of the primary. It is also > possible to use a third system (called a witness server) to prevent some > cases of inappropriate failover, but the additional complexity might not be > worthwhile unless it is set up with sufficient care and rigorous testing. > > PostgreSQL does not provide the system software required to identify a > failure on the primary and notify the standby database server. Many such > tools exist and are well integrated with the operating system facilities > required for successful failover, such as IP address migration." > > Can someone explain how the HA failback will take place and what open source > tools we can use to make sure once the primary server which failed over to > slave will mark itself as slave. > There are LOTS of ways to implement HA. Here's a book on the subject that's 537 pages long, and is only $4.99 right now: https://www.packtpub.com/big-data-and-business-intelligence/postgresql-high-availability-cookbook-second-edition I've been reading it a bit, seems to be a good resource. -- To understand recursion, one must first understand recursion.
Re: SSD filesystem aligned to DBMS
On Tue, Jan 16, 2018 at 7:47 AM, Neto pr wrote: > Hi all > > Sorry, but I'm not sure that this doubt is appropriate for this list, but I > do need to prepare the file system of an SSD disk in a way that pointed me > to, which would be a way optimized SSD > to work. I have a disk: SSD: Samsung 500 GB SATA III 6Gb/s - Model: 850 Evo > http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850evo/ > > One person on the list me said that should be partition aligned to 3072 not > default 2048, to start on erase block bounduary. And fs block should be 8kb. > > Can you give me a hint of what program I could do this. I have already used > fdisk but I do not know how to do this in Fdisk. I used Linux Debian > 8(Jessie) 64b with Ext4 File system. fdisk is pretty old and can't handle larger disks. You can get a fair bit of control over the process with parted, but it takes some getting used to. As far as I know, linux's ext4 has a maximum block size of 4k. I can't imagine alignment matters to SSDs and I would take any advice as such with a large grain of salt and then if I had questions about performance I'd test it to see. I'm willing to bet a couple bucks it makes ZERO difference. > > If you prefer, just reply to me, since the subject would not be about > postgresql itself. netopr...@gmail.com No this affects everybody who uses SSDs so let's keep it on list if we can.
