New IDS Server: 32 or 64bit?
A user upgrading from IDS 7.31 to IDS 10 on a new Xeon/SUSE SLES 10 box asked whether to install the 32- or 64-bit engine (small DBs, ~4GB, 2GB RAM) and how to lay out dbspaces when only a mirrored (RAID 1) disk pair is available. Replies generally said to go 64-bit if the CPU and OS support it, though with only 2GB RAM it makes little practical difference; 32-bit matters mainly on big-memory servers, where IDS is capped at roughly 2.7GB for buffers plus virtual memory. For layout, posters recommended separate dbspaces for root (with the physical log), logical logs and data, plus temp space, and noted IDS 10's larger page sizes and that cooked files are acceptable under light load if filesystem logging is on. No single formal conclusion is recorded, but the advice was consistent.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Dear Informixers,
we've been running IDS 7.31 engine on a Linux machine (SuSE 7.2) for over
6 years without any larger hassles. Now I have an opportunity to upgrade
to IDS 10 on a new(er) machine and have to decide whether to stay at 32bit
or go on to 64bit. Machine is a dedicated Intel XEON-based server, AFAIK this
platform supports both 32bit and 64bit versions of SuSE SLES 10. All database
connections (except for occasional "dbaccess" sessions on the server itself)
will come over the network from separate machine.
The databases are rather small, total volume is currently less than 4GB with
an annual growth rate of less than 500MB.
What benefit would I gain by going 64bit? What pitfalls should I take into
account? The server will have 2GB of RAM, which should be plenty for the
job and be usable for IDS10 in both the 32 and 64 Bit environment.
Another question: The new machine will have only 2 Disks, which I plan to
configure as RAID 1 (mirroring), so there will be no dedicated spindle(s)
for the database chunks. I've been following the various threads in this
newsgroup about optimal disk layout and usage, but most of the issues
discussed there don't really apply to my environment since the databases
and transaction volume are so small. What partitioning scheme for the
database engine would be advisable in my case? Just one partition for
everything, or two partitions (rootdbs and data), or even more?
Regards, Richard
On Mar 28, 7:34 am, Richard Spitz <Richard.Sp...@med.uni-muenchen.de>
wrote:
> Dear Informixers,
>
> we've been running IDS 7.31 engine on a Linux machine (SuSE 7.2) for over
> 6 years without any larger hassles. Now I have an opportunity to upgrade
> to IDS 10 on a new(er) machine and have to decide whether to stay at 32bit
> or go on to 64bit. Machine is a dedicated Intel XEON-based server, AFAIK this
> platform supports both 32bit and 64bit versions of SuSE SLES 10. All database
> connections (except for occasional "dbaccess" sessions on the server itself)
> will come over the network from separate machine.
>
> The databases are rather small, total volume is currently less than 4GB with
> an annual growth rate of less than 500MB.
>
> What benefit would I gain by going 64bit? What pitfalls should I take into
> account? The server will have 2GB of RAM, which should be plenty for the
> job and be usable for IDS10 in both the 32 and 64 Bit environment.
>
> Another question: The new machine will have only 2 Disks, which I plan to
> configure as RAID 1 (mirroring), so there will be no dedicated spindle(s)
> for the database chunks. I've been following the various threads in this
> newsgroup about optimal disk layout and usage, but most of the issues
> discussed there don't really apply to my environment since the databases
> and transaction volume are so small. What partitioning scheme for the
> database engine would be advisable in my case? Just one partition for
> everything, or two partitions (rootdbs and data), or even more?
>
> Regards, Richard
It is usually a good idea to split your data off from rootdbs and to
set aside separate temp spaces. In IDS 10 you can also create
dataspaces with larger page sizes. This may be useful for your
application if you have wide rows, for example. Whether you need
separate blob spaces depends on your application.
If your application is not very demanding, then you could get away
with running on a cooked file, if you turn on logging, so that the OS
could recover the files in case of power outage and other failures.
Don't run on cooked, non-logged files: the risk is too high. The extra
logging costs somewhat in performance, but since you have a low load,
it does not matter, and will enable you much more versatility and ease
of administration.
On 28/03/07, Richard Spitz <Richard.Spitz@med.uni-muenchen.de> wrote:
> Dear Informixers,
>
> we've been running IDS 7.31 engine on a Linux machine (SuSE 7.2) for over
> 6 years without any larger hassles. Now I have an opportunity to upgrade
> to IDS 10 on a new(er) machine and have to decide whether to stay at 32bit
> or go on to 64bit. Machine is a dedicated Intel XEON-based server, AFAIK this
> platform supports both 32bit and 64bit versions of SuSE SLES 10. All database
> connections (except for occasional "dbaccess" sessions on the server itself)
> will come over the network from separate machine.
>
> The databases are rather small, total volume is currently less than 4GB with
> an annual growth rate of less than 500MB.
>
> What benefit would I gain by going 64bit? What pitfalls should I take into
> account? The server will have 2GB of RAM, which should be plenty for the
> job and be usable for IDS10 in both the 32 and 64 Bit environment.
>
> Another question: The new machine will have only 2 Disks, which I plan to
> configure as RAID 1 (mirroring), so there will be no dedicated spindle(s)
> for the database chunks. I've been following the various threads in this
> newsgroup about optimal disk layout and usage, but most of the issues
> discussed there don't really apply to my environment since the databases
> and transaction volume are so small. What partitioning scheme for the
> database engine would be advisable in my case? Just one partition for
> everything, or two partitions (rootdbs and data), or even more?
>
> Regards, Richard
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
Richard
Even with just a single spindle I would still create 3 dbspaces. Root
(cos you have to have it, keep the physlog here but as little else as
possible to prevent it filling), logical logs (just to keep them
separate and allow logs to be added without weaving into your data too
much) and data for everything else.
32 or 64 is personal preference. I've got 64 on AIX with no issues,
cannot think of reasons one way or another, especially as the app is
connecting over the network.
Keith
You get better memory management if you go with the latest 2.6 Linux kernel,
as well as improved process management. The AMD server line has been excellent
for us with 32/64, and have seen no problems. AMD on laptops however has not
been as good with power management, but that's about the only issue I've heard
with AMD. I did hear Intel 32/64 was not good a year or so ago, but don't know
what it's like today. Intel has a 'code-sharing' arrangement with AMD, but has
had a lot of trouble implementing what AMD has done. I'm not sure if Intel is
in the lead right now on servers. On laptops the Intel line has been proven
to have better power management, but that's about all I've heard--and that's
only for 32bit. AMD is coming out with, or has already come out with, Quad core,
and/or Quad CPU server configurations that from what I've heard have been very
fast--but that's a very subjective statement, your results may be different.
Richard Spitz wrote:
> Dear Informixers,
>
> we've been running IDS 7.31 engine on a Linux machine (SuSE 7.2) for over
> 6 years without any larger hassles. Now I have an opportunity to upgrade
> to IDS 10 on a new(er) machine and have to decide whether to stay at 32bit
> or go on to 64bit. Machine is a dedicated Intel XEON-based server, AFAIK this
> platform supports both 32bit and 64bit versions of SuSE SLES 10. All database
> connections (except for occasional "dbaccess" sessions on the server itself)
> will come over the network from separate machine.
>
> The databases are rather small, total volume is currently less than 4GB with
> an annual growth rate of less than 500MB.
>
> What benefit would I gain by going 64bit? What pitfalls should I take into
> account? The server will have 2GB of RAM, which should be plenty for the
> job and be usable for IDS10 in both the 32 and 64 Bit environment.
>
> Another question: The new machine will have only 2 Disks, which I plan to
> configure as RAID 1 (mirroring), so there will be no dedicated spindle(s)
> for the database chunks. I've been following the various threads in this
> newsgroup about optimal disk layout and usage, but most of the issues
> discussed there don't really apply to my environment since the databases
> and transaction volume are so small. What partitioning scheme for the
> database engine would be advisable in my case? Just one partition for
> everything, or two partitions (rootdbs and data), or even more?
>
> Regards, Richard
>
--
*
* http://www.youtube.com/watch?v=rVS3kdXycrM&mode=related&search=
*
Go with 64Bit.
If your Chips/OS support 64 bit, then use it.
>
>Richard Spitz wrote:
> > Dear Informixers,
> >
> > we've been running IDS 7.31 engine on a Linux machine (SuSE 7.2) for
>over
> > 6 years without any larger hassles. Now I have an opportunity to upgrade
> > to IDS 10 on a new(er) machine and have to decide whether to stay at
>32bit
> > or go on to 64bit. Machine is a dedicated Intel XEON-based server, AFAIK
>this
> > platform supports both 32bit and 64bit versions of SuSE SLES 10. All
>database
> > connections (except for occasional "dbaccess" sessions on the server
>itself)
> > will come over the network from separate machine.
> >
> > The databases are rather small, total volume is currently less than 4GB
>with
> > an annual growth rate of less than 500MB.
> >
> > What benefit would I gain by going 64bit? What pitfalls should I take
>into
> > account? The server will have 2GB of RAM, which should be plenty for the
> > job and be usable for IDS10 in both the 32 and 64 Bit environment.
> >
> > Another question: The new machine will have only 2 Disks, which I plan
>to
> > configure as RAID 1 (mirroring), so there will be no dedicated
>spindle(s)
> > for the database chunks. I've been following the various threads in this
> > newsgroup about optimal disk layout and usage, but most of the issues
> > discussed there don't really apply to my environment since the databases
> > and transaction volume are so small. What partitioning scheme for the
> > database engine would be advisable in my case? Just one partition for
> > everything, or two partitions (rootdbs and data), or even more?
> >
> > Regards, Richard
> >
>
>--
>*
>* http://www.youtube.com/watch?v=rVS3kdXycrM&mode=related&search=
>*
>
>_______________________________________________
>Informix-list mailing list
>Informix-list@iiug.org
>http://www.iiug.org/mailman/listinfo/informix-list
_________________________________________________________________
Interest Rates near 39yr lows! $430,000 Mortgage for $1,399/mo - Calculate
new payment
http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-18466&moid=7581
"Keith Simmons" <smiley73@googlemail.com> wrote in message news:mailman.491.1175087706.10648.informix-list@iiug.org... > On 28/03/07, Richard Spitz <Richard.Spitz@med.uni-muenchen.de> wrote: > > Even with just a single spindle I would still create 3 dbspaces. Root > (cos you have to have it, keep the physlog here but as little else as > possible to prevent it filling), logical logs (just to keep them > separate and allow logs to be added without weaving into your data too > much) and data for everything else. > 32 or 64 is personal preference. I've got 64 on AIX with no issues, > cannot think of reasons one way or another, especially as the app is > connecting over the network. As I recall you have a pretty meaty p570 or something so you absolutely *should* care, because IDS on 32-bit servers can accomodate a total of about 2.7g only for buffer pool., virtual memory etc etc. Not only is it therefore a waste of a dedicated database server with 16g or whatever if the databasecan only address a fraction of it, plus if you have an application thirsty for virtual memory from the database you can end up having to reduce your buffer pool to a sub-optimal size to stay under the 2.7g limit. In Richard's case I don;t think it matters much because he's only got 2g of physical memory anyway so will want to keep Informix usage beneath that.