Subject | Re: [firebird-support] Re: Performance tuning large FDB |
---|---|
Author | Jan Bakuwel |
Post date | 2006-01-20T11:00:14Z |
Hoi Ali,
Thanks for replying.
utilising 64bit 'addresses'), it being a 32bit app does not necessarily
mean it is unable to address anything beyond a 32bit address. If it can
do it on disc, it can do it in memory I would say.
Firebird 1.5.1 (Debian Sarge package).
of records to read can be quite large for most queries. The DB is
already fully optimized, its just dealing with quite a lot of data...
I am looking for a way to make best use of the available RAM (8GB).
Either I can do that by using FB's built-in mechanisms such as the
different caches. This would be my ideal situation. I could also put my
hopes in the Linux caches...
Another approach would be to split the DB in two parts, and storing the
part that is searched most on a RAM disc. This will create cross
references between the two DBs. While it would be interesting to sort
out, I much prefer to keep focessed on the application.
Any more thoughts are very welcome!
cheers,
Jan
--
A journalist once asked the late Gandhi what he thought of the western
civilization. Gandhi replied: "Western Civilization? That would be a
good idea!".
----
Ships Unit
Information, Communication, Technology
Greenpeace International
Ottho Heldringstraat 5
1066 AZ AMSTERDAM
Netherlands (MET)
direct +31 (0)20 7182084
fax +31 (0)20 5148151
reception +31 (0)20 5148150
email jan.bakuwel&int.greenpeace.org
private jan.bakuwel&hccnet.nl
(replace & by @ in the emailaddress)
Thanks for replying.
> This parameters will be ignored FB or any 32bit application.I see your point. However, since FB is able to use >2GB files (by
> 819TonePages are out of range. (<10,000 suitable for <=FB1.x)
> 1 GB RAM for any allocation to sorting???
> 4 GB RAM for sorting operations???
>
> Jan, 32 bit executables can addressed only in 32bit range.
> FB cannot use this limit totally for sorting only.
utilising 64bit 'addresses'), it being a 32bit app does not necessarily
mean it is unable to address anything beyond a 32bit address. If it can
do it on disc, it can do it in memory I would say.
> if you want high performance, use hardware RAID systems.I am using a 3ware 3w7000 series SATA RAID controller. I'm running
> in high possibility your SATA RAID system is software based.
Firebird 1.5.1 (Debian Sarge package).
> First, can you show us your DB design and usege strategy to improveThe DB design is of course important. However, in this case the amount
> your performance?
of records to read can be quite large for most queries. The DB is
already fully optimized, its just dealing with quite a lot of data...
I am looking for a way to make best use of the available RAM (8GB).
Either I can do that by using FB's built-in mechanisms such as the
different caches. This would be my ideal situation. I could also put my
hopes in the Linux caches...
Another approach would be to split the DB in two parts, and storing the
part that is searched most on a RAM disc. This will create cross
references between the two DBs. While it would be interesting to sort
out, I much prefer to keep focessed on the application.
Any more thoughts are very welcome!
cheers,
Jan
--
A journalist once asked the late Gandhi what he thought of the western
civilization. Gandhi replied: "Western Civilization? That would be a
good idea!".
----
Ships Unit
Information, Communication, Technology
Greenpeace International
Ottho Heldringstraat 5
1066 AZ AMSTERDAM
Netherlands (MET)
direct +31 (0)20 7182084
fax +31 (0)20 5148151
reception +31 (0)20 5148150
email jan.bakuwel&int.greenpeace.org
private jan.bakuwel&hccnet.nl
(replace & by @ in the emailaddress)