Comment sybase ase on linux, considerations. (Score 2) 249
there are currently two versions of sybase for linux to concern yourself with. 11.0.3.3 and 11.9.2. one of the biggest differences is that 11.0.3.3 does not support raw partitions while 11.9.2 does. you will get much better performance from 11.9.2 using raw devices, also it lends towards better data integrity.
as for your system, you'll be amazed at how much you can accomplish with linux/intel. there are only two components that you really need to worry about, CPU busy and IO busy. if the system that currently houses your database is running sql, then you can run this to get an idea of how to set up a like system:
1> declare @loop_var int
2> select @loop_var = 0
3> while @loop_var begin
5> exec sp_monitor
6> select @loop_var = @loop_var + 1
7> waitfor delay 'yy:yy:yy'
8> end
where x = iterations and y = the delay in hr:min:sec.
run this during a "peak usage time", have the results dump to a file using the -o param and then
take a look at the CPU and IO. you'll get something like this:
cpu_busy io_busy idle
---- -------------------------
3(0)-0% 0(0)-0% 13863(5)-100%"
this is a sybase ase running on red hat at idle. during production you will want cpu_busy to be in the range of 60-70% as this allows for some growth, if you hit 80% or more start planning for more cpu power. conversely, if your io_busy is getting hit hard it may indicate problems with your network configuration, or that your device configuration needs tweaking. poor performance from a sybase server is not always cpu related.
i run a 10GB DB on an intel pIII 600(ish) with a 1/4 GB RAM and my cpu_busy sits around 65% most of the time. except when users try to dump the contents of their windows "c" drive into the database...grr.
hope that helps, ymmv of course.
-scroe
as for your system, you'll be amazed at how much you can accomplish with linux/intel. there are only two components that you really need to worry about, CPU busy and IO busy. if the system that currently houses your database is running sql, then you can run this to get an idea of how to set up a like system:
1> declare @loop_var int
2> select @loop_var = 0
3> while @loop_var begin
5> exec sp_monitor
6> select @loop_var = @loop_var + 1
7> waitfor delay 'yy:yy:yy'
8> end
where x = iterations and y = the delay in hr:min:sec.
run this during a "peak usage time", have the results dump to a file using the -o param and then
take a look at the CPU and IO. you'll get something like this:
cpu_busy io_busy idle
---- -------------------------
3(0)-0% 0(0)-0% 13863(5)-100%"
this is a sybase ase running on red hat at idle. during production you will want cpu_busy to be in the range of 60-70% as this allows for some growth, if you hit 80% or more start planning for more cpu power. conversely, if your io_busy is getting hit hard it may indicate problems with your network configuration, or that your device configuration needs tweaking. poor performance from a sybase server is not always cpu related.
i run a 10GB DB on an intel pIII 600(ish) with a 1/4 GB RAM and my cpu_busy sits around 65% most of the time. except when users try to dump the contents of their windows "c" drive into the database...grr.
hope that helps, ymmv of course.
-scroe
