Re: [PERFORM] requested shared memory size overflows size_t
Hey there; As Tom notes before maybe you're not using the right postgres. Solaris 10 comes with a postgres, but on SPARC it's 32 bit compiled (I can't speak to x86 Solaris though). Assuming that's not the problem, you can be 100% sure if your Postgres binary is actually 64 bit by using the file command on the 'postgres' executable. A sample from 64 bit SPARC looks like this: postgres: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped But x86 should show something similar. I have run Postgres up to about 8 gigs of RAM on Solaris without trouble. Anyway, sorry if this is obvious / not helpful but good luck :) Steve On Tue, Jul 15, 2008 at 10:25 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Uwe Bartels" <[EMAIL PROTECTED]> writes: > > When trying to to set shared_buffers greater then 3,5 GB on 32 GB x86 > > machine with solaris 10 I running in this error: > > FATAL: requested shared memory size overflows size_t > > > The solaris x86 ist 64-bit and the compiled postgres is as well 64-bit. > > Either it's not really a 64-bit build, or you made an error in your > math. What did you try to set shared_buffers to, exactly? Did you > increase any other parameters at the same time? > >regards, tom lane > > -- > 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] 3ware vs Areca
On Mon, Jul 14, 2008 at 9:13 PM, Greg Smith <[EMAIL PROTECTED]> wrote: > On Fri, 11 Jul 2008, Jeffrey Baker wrote: > >> Their firmware is, frankly, garbage. In more than one instance we >> have had the card panic when a disk fails, which is obviously counter >> to the entire purpose of a RAID. We finally removed the Areca >> controllers from our database server and replaced them with HP P800s. > > Can you give a bit more detail here? If what you mean is that the driver > for the card generated an OS panic when a drive failed, that's not > necessarily the firmware at all. I know I had problems with the Areca cards > under Linux until their driver went into the mainline kernel in 2.6.19, all > kinds of panics under normal conditions. Haven't seen anything like that > with later Linux kernels or under Solaris 10, but then again I haven't had a > disk failure yet either. Well, it is difficult to tell if the fault is with the hardware or the software. No traditional kernel panic has been observed. But most recently in my memory we had an Areca HBA which, when one of its WD RE-2 disks failed, completely stopped responding to both the command line and the web management interface. Then, i/o to that RAID became increasingly slower, and slower, until it stopped serving i/o at all. At that point it was not relevant that the machine was technically still running. We have another Areca HBA that starts throwing errors up the SCSI stack if it runs for more than 2 months at a time. We have to reboot it on a schedule to keep it running. -jwb -- 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] 3ware vs Areca
On Tue, 15 Jul 2008, Jeffrey Baker wrote: But most recently in my memory we had an Areca HBA which, when one of its WD RE-2 disks failed, completely stopped responding to both the command line and the web management interface. What operating system/kernel version are you using on these systems? -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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] 3ware vs Areca
On Tue, Jul 15, 2008 at 8:17 AM, Greg Smith <[EMAIL PROTECTED]> wrote: > On Tue, 15 Jul 2008, Jeffrey Baker wrote: > >> But most recently in my memory we had an Areca HBA which, when one of its >> WD RE-2 disks failed, completely stopped responding to both the command line >> and the web management interface. > > What operating system/kernel version are you using on these systems? Debian "etch", which has a 2.6.18 kernel. I have contacted Areca support (as well as the linux-scsi mailing list) and their responses are usually either 1) upgrade the driver and/or firmware even though I have the latest drivers and firmware, or 2) vague statements about the disk being incompatible with the controller. -jwb -- 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] requested shared memory size overflows size_t
"Uwe Bartels" <[EMAIL PROTECTED]> writes: > When trying to to set shared_buffers greater then 3,5 GB on 32 GB x86 > machine with solaris 10 I running in this error: > FATAL: requested shared memory size overflows size_t > The solaris x86 ist 64-bit and the compiled postgres is as well 64-bit. Either it's not really a 64-bit build, or you made an error in your math. What did you try to set shared_buffers to, exactly? Did you increase any other parameters at the same time? regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] requested shared memory size overflows size_t
Hi, When trying to to set shared_buffers greater then 3,5 GB on 32 GB x86 machine with solaris 10 I running in this error: FATAL: requested shared memory size overflows size_t The solaris x86 ist 64-bit and the compiled postgres is as well 64-bit. Postgresql 8.2.5. max-shm ist allowed to 8GB. projmod -s -K "project.max-shm-memory=(priv,8G,deny)" user.postgres Does anybody have an idea? Thanks. Uwe
