I am going to comment inline with your notes below in RED:
Hello Informix family,
Iam migrating Informix from Solaris 11 to Redhat 8 and at the same time from Informix 12.10 to 14.10.FC11
Go to 14.10.FC11w1 instead, there are several bug fixed in the .FC11w1 patch release making it more stable than the FC11 release.
1. On current Solaris we run on a virtual solaris zone with 56 cpu threads and we have good performance
You currently have 7 physical Sparc cores with 8 SMT threads each. Trading this for 8 Intel cores each with 1 main thread and 1 hyperthread. Best practice is to disable the hyperthreading for massive long running processes like Informix, so you really only have 8 threads instead of 56. That's a huge reduction in power. Note that Sparc SMT threads run at around 80% or better of the main thread, while an Intel Hyperthread runs at between 25% & 40% of the main physical thread and when utilized the performance of the main thread is reduced by several percentage points (all according to Intel documentation). I would recommend having at least 24 cores if you use Intel processors. I would also recommend that you would likely do better with AMD processors which offer 2 SMT threads per core both of which are usable! If you go with AMD you might get away with 16 cores.
he new cpu on Redhat physical machine have the following
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 207
Model name: INTEL(R) XEON(R) GOLD 5515+
Stepping: 2
CPU MHz: 3200.000
CPU max MHz: 4100.0000
CPU min MHz: 800.0000
BogoMIPS: 6400.00
Virtualization: VT-x
L1d cache: 48K
L1i cache: 32K
L2 cache: 2048K
L3 cache: 23040K
NUMA node0 CPU(s): 0-15
How many VPCLASS cpu can I configure?
according to IFX manuals is the number of cores -1, but i watched a video for Lester, he said the new cpu have better performance so we can create VPCLASS cpu 2 -3/core.
Yes. Based on testing that I did with the help of several other DBAs at different client sites back in the day, we determined that a single CPU VP can take advantage of roughly 500MHZ of CPU cycles. Beyond that the wait time for IO and server overhead limited making further use of the available cycles. So, with a 3GHZ processor, it would be possible to run between 4 and 6 CPU VPs per thread (except for Intel Hyperthreads - do not count these if you have not disabled them altogether).
2. Regarding memory I have 512 and this server is dedicated only for the database
I did allocate 300GB for Hugepage
what is recommended in this case can I allocate more ? if I have big buffer size, can this be a problem in case of any db crash ? or any other issue ?
That should be plenty of huge pages unless you think that you will need more than that for your buffer caches. I would just copy the settings for SHMVIRTSIZE and SHMADD that you are using now on Solaris! For the buffer caches, see below where you ask about that specifically.
3. I am changing from 2k page size to 4k.
Can I even create the logdbs,tempdbs,phydbs(plogdbs) with 4k and what is the benefits ?
No. The rootdb, logical logs, and physical logs have to live in default page sized dbspaces. On all platforms except AIX and Windows that is 2K pages. You should create a 2K rootdb dbspace of about 500MB or larger by setting the ROOTSIZE parameter in the ONCONFIG file before creating the instance. You should create a separate 2K dbspace just for the logical logs and a PLOG type dbspace for the physical log (dong that will automatically move the physical log - no need to use onparams to move it now).
I have few tables with records bigger than 4K, is it better to use 8k ? what
can go wrong ?
You should have a separate dbspace for wider tables. If a data row is wider than the dbspace's page size, then the tail end of the row will be gathered with a few other tails on a separate page requiring two IOs to fetch each row and two buffer cache pages to hold them.
In addition, since you have this opportunity to restructure your database, look into the waste on each 4K page for each significant table. For example, a 4K page can hold 4072 bytes of data and each row adds 4 bytes of overhead to its nominal length. So say you have a table with a 240 byte row. Each row needs 244 bytes so that means that 16 rows fit on a page with 168 bytes wasted on every page or 10.5 bytes per row. If that table has millions of rows that's a lot of waste! If you put that same table in an 8K dbspace then 33 rows fit on a page with 114 bytes waste per page or a bit less than 3.5 bytes per row. If you put that table in an 16K dbspace instead then 67 rows fit on a page with only 12 bytes wasted per page or less than 1 byte per row. So for my example table either 8K or 16K pages would be an major improvement over keeping it on a 4K page. I have scripts to perform the calculations for you because the calculation is more complex if your table's row size is variable (so VARCHAR, LVARCHAR, or other variable length data types included).
note when I only have those rows on onconfig, and init the instance it shows on the log it create a buffer for 2k , is it correct ?
OK, remember that the rootdb dbspace and logical and physical log dbspaces will still reside on 2K pages, so yes, you need a 2K bufferpool setting. Since you did not include an explicit BUFFERPOOL 2K entry the engine used the values in the "default" bufferpool setting (which is used to create any new bufferpool that needs to be created when you creat a new dbspace with a page size that there is not an entry in the ONCONFIG file for).
BUFFERPOOL default,
BUFFERPOOL size=4K,
Set the "default" entries using a reasonable number of buffers so that any dynamically created dbspaces will be useful and reasonably efficient without having to bounce the instance. For the 2K buffer pool, run onstat -P on your current server and count up the number of pages for all of the entries with a partnum that is seven digits starting with a '1'. Those are your current contents of the rootdb dbspace. Use that count to size your 2K bufferpool, assuming that none of your databases and user tables will reside in 2K dbspaces.
The remaining buffer pool pages, adjusted for page size, will be a good starting value for your 4K buffer pool.
4. I use to create the physical log as any dbspace and do changes with onparams to move from rootdbs, what is the different between the old way and the plogdbs ?
Two differences between using a "normal" dbspace and a PLOG type dbspace for your physical log: 1) creating the PLOG space and moving the physical log is a single operation, so no need to run onparams afterwards, and 2) The PLOG dbspace is extendable by default, so if the engine needs to expand the physical log it can just make it bigger and the dbspace (assuming it is build in a filesystem file and not a raw device) will just grow.
5. I have watched many video about ifx performance all recommend to use 16k dbspaces for indexes, can you se any issue with that even if the indexes are small ?
OK, there is little or no performance advantage to using wider pages for an index on a small table, especially if the index key is itself narrow. The advantages of putting indexes on wider pages is twofold: 1) The performance improvement by pulling in more index keys and nodes with each index IO, and 2) You can have a wider maximum key size if the index resides on wider pages. A page size of 16K seems to be ideal for indexes for most larger tables. Note that I would recommend that indexes, regardless of the page size you choose for them, reside in a separate dbspace from your table data. So, ideally you should have a 2K or 4K dbspace for smaller indexes and a 16K dbspace for larger indexes in addition to having one or more dbspaces for your tables.
Many thanks in advance
Art S. Kagel, President and Principal Consultant
Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.