Re: What HW / OS is recommeded
От | Alex |
---|---|
Тема | Re: What HW / OS is recommeded |
Дата | |
Msg-id | 41C23201.3010201@meerkatsoft.com обсуждение исходный текст |
Ответ на | Re: What HW / OS is recommeded (Scott Marlowe <smarlowe@g2switchworks.com>) |
Ответы |
Re: What HW / OS is recommeded
|
Список | pgsql-general |
We use perl for the heavy batch jobs, the web interface is written using JSP / applets. If we would change these then it would be Java or C. But all the heavy stuff is handled by Stored Procedures so I dont see a real need for a change. I actually am more interested to hear if there are an recommended systems or setups. Also with regard to 2/4 CPUs or 32/64 bit etc. Scott Marlowe wrote: >On Thu, 2004-12-16 at 06:39, Michael Ben-Nes wrote: > > >>I think and please correct me that Postgres loves RAM, the more the better. >> >>Any way RAID5 is awful with writing, go with RAID1 ( mirroring ) >> >> > >With battery backed cache and a large array, RAID 5 is quite fast, even >with writes. Plus with a lot of drives in a mostly read environment, >it's quite likely that each read will hit a different drive so that many >parallel requests can be handled quite well. The general rule I use is >6 or fewer drives will do better in RAID 1+0, 7 or more will tend to do >better with RAID 5. > > > >>Perl is very slow, maybe you can use PHP ? >> >> > >While mod_perl and its relations have never been fast running under >apache in comparison to PHP, it's no slouch, paying mostly in startup >time, not run time. For complex apps, the startup time difference >becomes noise compared to the run time, so it's no big advantage to >PHP. I really like PHP by the way. But Perl is pretty nice too. > >Run the Unix OS you're most comfortable with, knowing that PostgreSQL >gets lots of testing on the free unixes more so than on the commercial >ones. Give it a machine with plenty of RAM and a fast I/O subsystem, >and two CPUS and you'll get good performance. If your needs exceed the >performance of one of these machines, you're probably better off going >to a pgpool / slony cluster than trying to build a bigger machine. > > > >
В списке pgsql-general по дате отправления: