The company has had an information system that has been in operation for many years. Data has been accumulated for about three years.
The database uses oracle. Due to the rush of system development, heap fields are used during development, and various related methods are used to design.
There are often more than 500 lines of SQL statements, often the system performance is poor, and users complain that the system is stuck and slow.
After analysis, there are multiple SQL statements that often exceed 20 seconds, and some batch operations will make oracle suspended.
As a result, the database had to be restarted in order to restore the system to normal.
After detailed analysis, it is found that there are too many places to directly stack the code, and the basic business logic is operated in the database.
Many complex business logic is basically operated in the database.
The program is relatively simple, and a large number of businesses are implemented in SQL statements.
The performance bottleneck presented here is obvious, basically 90% of the time is in the database, and the resources of the web system are basically idle.
Because there are more than tens of thousands of lines of similar code, there are many possibilities to modify them one by one, and various new defects will be caused after modification.
Therefore, the possibility of improving performance by modifying the code is very low.
Some conclusions with poor performance analyzed:
1) A lot of business logic is written in SQL statements, and the pressure is concentrated on the database;
2) The business logic is complex, there are many associations between codes, and the code is difficult to modify and optimize;
3) Basically no index is used, and the query efficiency is extremely poor;
4) The log data is written in the database;
5) There are many fields output by the query, and the average output of each query exceeds 50 fields;
6) The fields of the key table exceed 400, and the table structure can no longer be maintained;
7) Using oracle database, less maintenance operation space;
feature:
8) The total data volume is not very large, the entire database (three years of data, including all request logs) does not exceed 50G
Solutions:
1. Change the code
Method: Find out the requests with poor performance, then separate the SQL statements, and put some business-related logic in the program for processing.
The database only does simple queries, inserts, and modifications.
Problem: The development cost is relatively high, a lot of code needs to be modified, and the modification time is relatively short, which often causes other defects.
The optimization situation is not obvious, and the output fields are still relatively large.
Conclusion: Takes too long.
2. Do a cluster
The technical ability to do clustering is insufficient, and the data is relatively small.
Need to invite oracle related people to come.
Conclusion: The effect of improvement is not obvious, or basically has no effect.
3. Heap hardware
Increase the memory of the database server;
Change the disk to SSD and do RAID 10;
Conclusion: After the test, the performance has improved greatly, and many consuming about 40 seconds have become about 10 seconds.
4. Heap hardware + software processing
Going a step further in this direction, since the performance boost is very effective with the addition of hardware.
It is found that the performance improvement of increasing memory is basically pushed to zero.
The improvement of the disk, especially after replacing the SSD, the performance has been significantly improved.
Therefore, there needs to be something more powerful than SSD to replace. At this point, I directly thought of memory.
Now that the memory is relatively cheap, I thought of setting up a memory disk.
By virtualizing memory into a disk, commonly known as RamDisk, and then putting database data into RamDisk.
At this time, you are generally worried about the problem of data security. There is a solution to this problem, which can be discussed later.
Conclusion: It is estimated that the performance will be improved qualitatively, and the data security problem needs to be solved.
The key is not to modify any logic code of the original business. decided to take this step.
Test Phase 1:
Test objective: Put the tablespace file of the database into RamDisk, query complex statements, and obtain the performance difference relative to the conventional SSD.
Preparation process:
1. Create a 32G RamDisk disk.
2. Install oracle into RamDisk.
3. Create a tablespace file and put the file location into RamDisk.
4. Import the production environment database and name this database ramDb.
5. Find the slowest SQL statement for system query, name this business slowJob1, and query only.
Execute the SQL process:
Execute the slowJob1 statement in the production environment database to output data of about 20w, which takes 40s.
Execute this statement in the RamDB database, if the input is the same, it will take 1s.
Simple conclusion:
At least using RamDisk can effectively improve query efficiency. The query results are the same.
think:
Since the difference between the read and write efficiency of the memory and the read and write efficiency of the disk is 10 times as large, the related problems of data read performance can be basically ignored.
No matter how complicated the query and how complicated the data read, there is basically no need to consider the impact of disk performance.
The only thing that needs to be considered more at the moment is data capacity and security.
Data capacity issues:
Since the data for three years does not exceed 50G, there are 20G log data in 50G, that is, 30G of business data.
With a 6-year design, the data volume is about 30*2=60G, which means the RamDisk can be designed to 64G to handle the 6-year data volume.
128G of space can support 10 years.
Thinking about data security:
Since memory carries the risk of data loss from a power outage, data needs to be stored on a reliable disk.
Read-write separation is a better solution.
When writing data, it writes memory blocks and disk blocks. When reading, only the memory block is read.
Under this logic, there are several modes:
1) Security type: After writing to the disk securely, the operation is completed.
2) Performance type: After writing to memory, it returns and writes to disk asynchronously.
The first type has slower write performance, the second type is faster at the risk of data loss.
The two can be decided according to the situation, there is no unified solution.
In the current project, the number of write operations is far less than the number of reads, and the write content is not high. Under the use of SSD+Raid10, the performance is sufficient.
Security will be selected.
Implementation of the scheme:
1. Simple and fast solution
Server 64G memory, SSD250G raid 10;
using windows 2008;
Use Rubik's cube memory disk, set 54g memory;
virtual memory is set on ramdisk;
Install oracle, oracle data folder is set on ramdisk;
Build a library and set the tablespace on the ramdisk;
Risks: The software is not stable enough, the stability of the Rubik's cube is relatively poor, and it will hang once a month.
The data is not safe enough, and manual work is required to save the memory data to the disk.
Second, based on linux module implementation
Server 64G memory, SSD250G raid 10;
install centos 6.5;
Install the RamDisk module (requires development, and an article will be written separately);
RamDisk space setting size is 54G;
Configure the mapping file in RamDisk to /home/oracle/ram.img, write synchronous mode;
The /dev/ramdisk device will appear after installing the RamDisk module
mkfs.ext4 /dev/ramdisk
mkdir /home/oracle/ramdisk
mount /dev/ramdisk /home/oracle/ramdisk
Install oracle, oracle data folder is set on ramdisk;
Build a library and set the tablespace on the ramdisk;
The RamDisk module needs to monitor all write operations of the ramdisk and synchronize the data to /home/oracle/ram.img
When the system is restarted, /home/oracle/ram.img will be automatically synchronized into /dev/ramdisk;
Benefits: Data security, and the performance of reading data is significantly improved.
Risks: Maintenance operations are relatively complex and require the development of RamDisk modules.