WO2015145595A1

WO2015145595A1 - Computer system and method for managing computer system

Info

Publication number: WO2015145595A1
Application number: PCT/JP2014/058400
Authority: WO
Inventors: 青木　英郎; 博泰西山; 有哉礒田; 知広花井; 敦友田; 一智牛嶋; 田中　剛; 昌忠高田; 匡邦揚妻
Original assignee: 株式会社日立製作所
Priority date: 2014-03-26
Filing date: 2014-03-26
Publication date: 2015-10-01
Also published as: JPWO2015145595A1

Abstract

　Provided is a technique for avoiding a delay in the performance of a high-priority program in a computer system, configured from a multi-core processor, in which a plurality of programs operate. The core and memory that a program uses is allocated by using computer configuration information, program definition information, inter-program reference information, and the freshness of data cooperation. Furthermore, to enable a high-priority program to refer to and/or update data preferentially, access control is exerted, at the time of access, that selects data on the basis of priority and the freshness of information, the data being accessible by a low-priority program, and adjusts the frequency with which the data is accessed.

Description

Computer system and computer system management method

Related to computer management methods.

Computer technology has evolved, and large-scale servers equipped with large-capacity memory and many cores have appeared. Databases that support mission-critical business (OLTP (Online Transaction Processing), ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), etc.) are one of the largest servers in terms of memory capacity and computing power. It can be realized in-memory. In addition, there is a growing expectation that business analysis will become more sophisticated and big data analysis will be utilized in business, and it is required to quickly use the data in the core business database as a database for information business.

Japanese Patent No. 4293794 Japanese Patent No. 4833590

When a single in-memory DB engine is operated for multiple DB systems on a large-scale computer, high-speed execution is required due to execution of multiple transactions and memory access delays when data of other DB systems required by each DB system is referenced. The transaction processing performance of a simple DB system is degraded.

In order to solve the above-described problems, a typical computer system of the present invention is a computer system including a plurality of processors, the processor includes a plurality of cores and a memory, and a thread for executing an application program is included in the core. A thread allocation unit for allocating and a data allocation unit for allocating data used in the application to the memory, and the thread allocation unit executes a high-priority thread that is a thread for executing a high-priority application and a low-priority application. A low-priority thread that is a thread is assigned to a core of a different processor, and the data allocation unit accesses the memory associated with the processor to which the high-priority thread is assigned by both the high-priority thread and the low-priority thread. Store common data It is realized by a computer system for assigning data.

処理 Lower priority application processing can reduce the impact on higher priority application processing.

The example of the computer system which this invention makes object is shown. It shows how the database management system operates on the server in the embodiment. The database management system configuration information for the database management system to operate in the embodiment is shown. The example of the DB instance definition file of OLTP in an Example is shown. The example of the DB instance definition file of CRM in an Example is shown. The example of the topology information in an Example is shown. The example of the allocation information in an Example is shown. The example of DB information in an example is shown. The processing flow of the database management system in an Example is shown. The processing flow of the database management system in an Example is shown. The example of allocation of DB instance which shares the data in an Example is shown. The example of allocation of DB instance which does not share the data in an Example is shown. The conceptual diagram at the time of the thread which performs transaction processing in an Example accesses data is shown. The processing flow of the access control part in an Example is shown. The processing flow of the access control part in an Example is shown.

Hereinafter, examples will be described with reference to the drawings.

FIG. 1 shows an example of a computer system targeted by the present invention. The server 101 is connected to a plurality of clients (client 1 (105), client 2 (106), client N (107)) via the network 103. The server 101 receives a request from an application program (APP) running on the client, and transmits the result processed by the server 101 to the client APP.

The server 101 is mainly composed of nodes and buses that connect the nodes. The bus is called a system interconnect bus. The system interconnect bus may exist as one bus, or may be configured by a combination of a bus and a controller, such as

system interconnect buses

190 and 191 and a controller 193 as shown in FIG.

A plurality of nodes (node 1 (110), node 2 (130), node 3 (150), node 4 (170)) are connected to the

system interconnect buses

190 and 191. In each node, a processor and a memory are directly connected. The processor is connected to the device via the I / O controller.

For example, in the node 1 (110), the processor 1 (114) has four cores, that is, a core 118, a core 119, a core 120, and a core 121. Further, the processor 1 (114) has a memory controller 1 (116) and is connected to the memory 1 (112). The secondary storage device 1 (124) and the communication device 1 (128) are connected to the I / O controller 1 (122) in the node 1 (110).

The secondary storage device 1 stores a part of files used in the server 101. Specifically, a program 125, data 126, and a log 127 are stored. In FIG. 1, the configuration and role of each node are the same as those of the node 1 (110).

The server 101 is a computer called NUMA (Non-Uniform Memory Access). Each core in each processor can access all memory.

However, the access speed differs depending on which core reads or writes to which address. For example, the core 118 in the node 1 can access the memory 1 (112) at a higher speed than the memory 2 (132). The core 118 can access the memory 1 via the memory controller 1 (116) of the processor 1 (114). However, since the core 118 accesses the memory 2 (132) via the interconnect bus 190, the access latency is large.

Furthermore, for the core 118, the memory 2 (132) can be accessed at a higher speed than the memory 3 (152) even in the memory access via the interconnect bus. The core 118 accesses the memory 2 (132) via the system interconnect bus 190, whereas when accessing the memory 3 (152), in addition to the system interconnect bus 190, the system interconnect bus 191 and the controller 193 It is because it is necessary to go through.

From the viewpoint of software operating on the server 101, the processor that executes the calculation corresponds to 270 including the processors of the respective nodes. The memory corresponds to 200 including the memory of each node. An execution file of the operating system 260 is stored in the secondary storage device connected to the node, although it is not explicitly shown.

The operating system 260 operates on the processor 270 and the memory 200, and further manages various resources for the application to operate on the processor 270 and the memory 200. The operating system 260 provides processor and core affinity functions for applications. Applications can run on specific processors and cores by requesting the operating system 260 using the affinity feature.

In addition, the operating system 260 provides a function for designating a memory allocation policy for an application. Thereby, the application can request the operating system 260 to allocate the virtual memory area used by the application from the physical memory of the specific node.

FIG. 2 shows how the software, particularly the database management system, operates on the server.

The database management system 220 is software that guarantees atomicity, consistency, separation, and persistence of data. The database management system 220 is an application program under the management of the operating system 260 and operates as a plurality of processes and threads.

FIG. 2 illustrates the main configuration of the database management system 220. Although not shown in FIG. 2, the database management system 220 includes a plurality of parts in order to accept a request from a client application described in SQL and process the request as a transaction. Specifically, there are modules for network connection management with a client and connection / communication management for transmitting and receiving data. In addition, there is a transaction management unit that manages basic information for realizing a transaction such as reference and update of data requested by a client.

In addition, there is a SQL management unit that manages an SQL language analysis and execution plan used as a data operation request to the database management system 220. In the database management system 220, data is generally managed as a table, and a table management unit is provided for this purpose. Further, the database management system 220 can use an index so that a transaction can access data to be operated at high speed, and has an index management unit for this purpose.

In the database management system 220, a database management thread 360 and a topology management thread 370 operate to manage the whole. In the database management thread 360, database information that operates on the database management system 220 is held in the DB information 362. The allocation information 364 holds the total amount of resources such as cores and memories that can be used by the database management system 220, the usage state and the usage amount in each instance. The database management thread 360 has a thread allocation unit 380 for managing threads of the database management system 220.

Also, a data allocation unit 382 exists to manage allocation of data to memory. The topology management thread 370 acquires configuration information of the server 101 from the operating system 260 and holds it as topology information 372.

The database management system 220 has an access control unit 384 for managing internal data access. Further, the database management system 220 records operation information as logs (127, 147, 167, 187) in the secondary storage of the server 101 in order to make the data operation from the client permanent. The log generation unit 386 manages log data. Further, the operation information and performance information of the entire database management system 220 are held as statistical information 390 and can be referred to through a database management interface (not shown).

The database management system 220 operates as an in-memory database that can execute a plurality of DB instances.

DB instance is composed of multiple threads and has independent storage area and independent control. The memory secured by the database management system 220 is allocated to each DB instance by the data allocation unit 382. For the allocated memory, the memory management thread of each DB instance manages the memory required in the DB instance. Also for the database log, the log management thread of each DB instance records the database operation information in the secondary storage using the function of the log generation unit 386.

2, a DB instance 1 (300) that realizes online transaction processing (OLTP) and a DB instance 2 (330) that realizes customer relationship management (CRM) are operating on the database management system 220.

OLTP is an important database in mission-critical systems, and must execute a large number of transactions at high speed. The CRM is a database for performing customer management based on OLTP information. The importance in the backbone system is lower than that of OLTP.

Conventionally, OLTP data used by CRM is processed by executing batch processing at a regular frequency such as once a day, extracting the change history from the OLTP database, and loading the change history into the CRM. Was sharing. With the development of computer technology, multiple databases such as OLTP and CRM can be executed on a single computer. In the present embodiment, by executing a plurality of DB instances of a database on a single in-memory database management system, sharing is possible without batch processing.

The DB instance 1 (300) is a DB instance for OLTP, and the transaction thread 1 (302) and the transaction thread 2 (306) operate in order to execute the transaction 1 (304) and the transaction 2 (308). ing.

The DB instance 1 (300) manages five pieces of information including store information 310, inventory information 312, product information 314, order information 316, and customer information 318 as table data. Among these, the order information 316 and the customer information 318 can be shared with other DB instances. The memory management thread 1 (320) manages the memory secured for the DB instance 1 (300) to operate. The log management thread 1 (322) generates and manages a log of online transaction processing.

DB instance 2 (320) is an instance for CRM and has inquiry information 340, sales promotion information 342, sales information 344, order information 346, and customer information 348 as table data. Of these, the order information 346 is realized by referring to the order information 316 of the DB instance 1. Similarly, the customer information 348 is realized by referring to the customer information 318.

As described above, since OLTP is a system with higher importance than CRM, DB instance 1 (300) is required to operate in preference to DB instance 2 (320). That is, the priority of DB instance 1 (300) is higher than the priority of DB instance 2 (320).

Therefore, the process and thread (302, 306, 320, 322) of the DB instance 1 (300) operate with priority over the process and thread (332, 336, 350, 352) of the DB instance 2 (320).

In order for the processes and threads that make up a DB instance to operate with priority over another DB instance, it is necessary to prevent the shared resources from being obstructed by the DB instance with a lower priority. Conventionally, a parallel processing control method in the case where one database is used by a plurality of users has been considered. The present embodiment relates to a processing method when a plurality of databases partially sharing data are used by a plurality of users. In the embodiment, OLTP and CRM are described, but the database used in combination may be ERP or OLAP (Online Analytical Processing).

FIG. 3 shows database management system configuration information for the database management system to operate. This data is stored as data (126, 146, 166 or 186) in the secondary storage device of the server 101 as a file, and is read by the database management thread 360 when the database management system 220 is activated. The number of nodes 405 describes how many nodes of the server 101 the database management system 220 uses.

In FIG. 3, all nodes are set to be used. The number of cores 410 describes the number of cores of the processor that can be used by the database management system 220 as a whole.

The memory size 415 indicates a memory size secured from the operating system 260 when the database management system 220 operates. The DB shared memory size 420 indicates the memory that is shared between DB instances and the amount of memory that is used for overall management when a plurality of DB instances operate on the database management system 220. The DB instance definition file 425 indicates a DB instance setting file that is loaded after the database management system 220 is activated. In FIG. 3, DB instances for transaction processing (OLTP) and customer relationship management (CRM) are set.

FIG. 4 shows an example of an OLTP DB instance definition file in the embodiment. The DB instance definition file 500 is used to start the DB instance 1 (300) of OLTP. The DB instance name 505 is an identifier for the system administrator to identify the DB instance on the database management system 220.

The priority 510 indicates an execution priority set for each DB instance when a plurality of DB instances operate on the database management system 220. “1” set in the priority 510 indicates that the operation is performed with the highest priority. The memory capacity 515 is a size allocated in the database management system 220 in order for the DB instance to operate. The shared memory capacity 517 is the size of memory allocated in the database management system 220 so that the DB instance can be used for data sharing with other DB instances. Based on this information, the data allocation unit reserves memory for the DB instance.

The number of cores 520 is the number of cores assigned to operate the DB instance. In this embodiment, the thread assignment unit 380 of the database management system 220 assigns one DB instance to one core of the server 101 (two or more DB instances do not use the same core). The maximum transaction 525 indicates the number of transactions to be processed by the DB instance per second. The average response time 530 indicates a target average processing time of a transaction processed by the DB instance.

The management table information 535 indicates table data information that is managed by the database management system 220 as an owner among the tables used in the instance. In addition to the table name (identifier), the management table 535 includes information indicating whether or not the table can be shared with other DB instances, and whether or not to partition the data using a key value such as an ID. They are defined together. The management table information 535 defines that store information, inventory information, and product information cannot be shared, and that order information and inventory information can be shared. The OLTP DB instance definition file 500 does not use partitioning for any table.

In this embodiment, the table schema is described as being defined in another data file. In the reference table 540, information on tables owned by other DB instances is described in the DB instance. Since DB instance 1 (300) does not refer to the tables of other DB instances, there is no setting.

In the initial data file 545, a file storing data to be loaded when the DB instance 1 (300) is started is set. The port number 550 stores a port number designated when a client (client 1 (105), client 2 (106), client N (107)) issues a request to the server 101.

FIG. 5 shows an example of a CRM DB instance definition file in the embodiment. DB instance name 605, priority 610, memory capacity 615, shared memory capacity 617, number of cores 620, maximum number of transactions 625, average response time 630, initial data file 645, and port number 650 have different values from the definition file 500. Is set. In the management table 635, information of table data owned by the DB instance 2 (330) is set.

Inquiry information, sales promotion information, and sales information are defined as table data that cannot be shared and that are not partitioned. The reference table 640 shows information about the table table defined by the DB instance 1 (OLTP). The order information indicates a table data order of an instance activated by the identifier OLTP, and means a table table of order information defined by the management table 535. The same applies to customer information. The priority of CRM is “3” defined in 610, and OLTP is processed with higher priority. As for the OLTP data to be referred to, it is defined that data that is 10 minutes old can be used.

FIG. 6 shows an example of topology information. The node number 705 indicates which node information.

In this example, 1 which is the value of the node number 705 is used to mean the node 1 (110) of the server 101. The number of processors 710 indicates the number of processors mounted on the node. Since the number of processors mounted on the node 1 (110) of the server 101 is 1, it is “1”. The number of cores 715 indicates the number of cores existing in the node. The memory 720 indicates the memory capacity installed in the node.

In this example, 32 GB of memory is installed in each node. For the distance 725, the cost for accessing each node is substituted. In this example, when viewed from the node 1, the access cost to the node 2 is 20. When viewed from the node 1, the access cost to the

nodes

3 and 4 is 40 because it is necessary to use the controller 193 of the server 101 and the system interconnect bus 191. In the device 730, a device mounted on each node is recorded. Regarding the server 101, the communication device of each node also corresponds, but the description is omitted.

The distance 725 can be acquired by, for example, the topology management thread 370 of the database management system 220 inquiring the operating system 260. In the case of Linux (R), it is obtained by executing the numactl command.

In this example, the value indicates the load when data is referred / updated between the nodes, and the value indicating the load is 10 when the data is referred / updated between the

nodes

1 and 1. On the other hand, the value indicating the load when data is referred / updated between the node 1 and the node 4 is 40.

FIG. 7 shows an example of allocation information in the embodiment. The large item 1700 is used to distinguish whether the set content is information on the entire database management system 220 or information specific to each DB instance. An item 1702 indicates an element to be assigned. Node 1704 is used to specify whether the assigned element is a node or the entire server. The allocation 1706 indicates the total amount that can be allocated by each node or the whole. The free space 1708 indicates the current free space with respect to the total amount that can be allocated. The use instance ID 1710 is used to manage which DB instance is used when resources are allocated. In the case of a memory, not only the capacity but also information such as a start address and an end address is required, but it is not shown.

Numerals 1722 to 1730 indicate information related to core allocation of the entire database management system 220. In this example, the cores of node 1 are all assigned to DB instance 1 (1722). Reference numerals 1732 to 1740 indicate information related to memory allocation of the entire database management system 220. In this example, the memory of the node 1 is secured by the database management system 220 by 25 GB, used by the DB instance 1, and has a free capacity of 1 GB.

1742 to 1750 indicate information related to the core allocation of the DB instance 1 (300). In this example, DB instance 1 (300) is assigned the core of node 1. Reference numerals 1752 to 1764 denote information related to memory allocation of the DB instance 1 (300). The DB instance 1 (300) reserves 20 GB from the node 1 (1752).

Occupancy 1762 is an area for recording a memory node to which an occupancy management table is allocated. The share 1764 is an area for recording a memory node to which a shareable management table is recommended. In the use instance ID of the share 1764, the ID of the DB instance that uses the shareable management table of the DB instance is recorded. In this example, since the memory size required by the DB instance 1 is not large, the node 1 is allocated for both occupation and sharing, and the DB instance 2 refers to the shareable management table.

After 1780, the allocation information is DB instance 2 (330). Since the data configuration is the same as that of 1742 to 1764 of DB instance 1 (300), the description is omitted.

FIG. 8 shows an example of DB information in the embodiment. The ID 1800 stores a DB instance ID for which information is set. An item 1802 indicates an item to be registered. Value 1 (1804) and value 2 (1806) are areas for storing necessary setting values for each item. The contents set in the DB information 362 are based on the DB instance definition file (500, 600) of each DB instance.

1820 to 1852 indicate DB information of DB instance 1 (300) that processes OLTP. The status 1820 currently indicates the state of the DB instance. This example shows that the core and memory allocation has been completed. The memory capacity 1826, the shared memory capacity 1827, and the number of cores 1828 store the unallocated resource amount in the value 2 (1806) as well as the setting value of the DB instance definition file. In this example, since the allocation is completed, the unallocated resource amount is zero. In the sharable management tables 1842 and 1844, DB instance IDs that may be referred to are stored.

1854 to 1862 indicate DB information of DB instance 2 (330) that processes the CRM. In the reference table 1860, based on the DB instance definition file 600, the reference freshness of the customer table is set to 10 minutes. As shown in FIG. 5, this means that CRM refers to a customer table held by OLTP, but it is allowed to refer to customer data 10 minutes ago.

FIG. 9 shows the processing flow of the database management system.

Step 805: The topology management thread 370 acquires the hardware configuration information of the server 101 from the operating system 260.

Step 810: The topology management thread 370 generates topology information based on the acquired hardware configuration information and registers it as topology information 372.

Step 815: The database management thread 360 reads the database management system configuration information 400 as the configuration information of the database management system 220, and creates DB information 362.

Step 820: The data allocation unit 382 of the database management thread 360 determines the memory size to be allocated from the node set to the node number 405 with reference to the topology information 372 in order to secure the memory size 415 of the database management system configuration information 400. To do. For example, a size obtained by dividing the set memory size by the number of nodes to be used is set as a memory size to be secured per node. The data allocation unit 382 of the database management thread 360 registers the memory size acquired from each determined node in 1732 to 1740 of the allocation information 364.

Step 825: The thread allocation unit 380 of the database management thread 360 determines the number of cores specified in the core number 410 of the database management system configuration information 400 with reference to the topology information 372. If the number of cores in the node used by the data allocation unit 382 is greater than or equal to the number of cores 410, the thread allocation unit 380 determines a core number to be used from among the nodes used by the data allocation unit 382.

When the number of cores in the node used by the data allocation unit 382 is smaller than the number of cores 410, the thread allocation unit 380 refers to the distance 725 of the topology information 372. The thread allocation unit 380 selects a node that is close to the node used by the data allocation unit 382 and determines the remaining cores to be used.

The database management thread 360 registers the determined number of cores in the allocation information 364.

Step 830: The database management thread 360 reads one file specified in the DB instance definition file 425 of the database management system configuration information 400.

Step 835: The database management thread 360 registers the information of the DB instance definition file (for example, the definition file 500) in the DB information 362. When there is definition information in the reference table / freshness (540, 640) of the DB instance definition file, the database management thread 360 registers the ID of the DB instance in the shareable management table of the DB instance to be referenced. For example, the CRM registers 2 as the CRM DB instance ID in the shared management table 1844 to refer to the OLTP customer.

Step 840: The database management thread 360 determines whether there is an unread file among the files written in the DB instance definition file 425 of the database management system configuration information 400. If there are other files to read, the process returns to step 830. Otherwise, go to 850.

FIG. 10 shows the continuation of the processing flow of FIG.

Step 905: The database management thread 360 refers to the DB information 362 and selects the DB instance with the highest priority from among the DB instances that are not assigned. The database management thread 360 sets the status (1820, 1854) of the DB information 362 for the selected DB instance during allocation.

Step 910: The data allocation unit 382 refers to the partitioning 1834 or the like in the DB information 362, and determines whether or not the DB instance uses partitioning. When partitioning is not performed, allocation is determined as follows.

The data allocation unit 382 refers to the DB information 362 and determines whether the DB instance refers to data of another DB instance from the occupancy management table, the sharable management table, and the reference table.

The data allocation unit 382 determines the node to which the occupancy management table is allocated based on the priority and the presence / absence of reference to another DB instance. When the priority of the DB instance is high and data of another DB instance is not referred to, the data allocation unit 382 refers to the entire free area (the free GB 1708 of 1732 to 1740) of the allocation information 364 and performs the allocation. Allocate memory from an unassigned node. When the priority of the DB instance is low and the data of the other DB instance is not referred to, the data allocation unit 382 refers to the allocation information 364 and the topology information 372, and is a node far from the node where the allocation has already been performed. Reserve memory above.

When the data of another DB instance is referred to and the allocation of the other DB instance is completed, the data allocation unit 382 refers to the allocation information 364 and the topology information 372, and is at a distance close to the node used by the DB instance to be referred to. Reserve memory on a node. At this time, when the priority of the DB instance is high, the memory is allocated from a node that is not allocated among the nodes at a short distance.

If the requested memory amount (capacity set in the memory capacity 1826) cannot be secured only by the selected node, the data allocation unit 382 refers to the distance 725 of the topology information 372 and the memories 1732 to 1738 of the allocation information 364. Then, memory is allocated from a node that is close to the already selected node.

The data allocation unit 382 subtracts the secured memory size from the entire free area (free GB 1708 of 1732 to 1740) of the allocation information 364. Further, the secured memory size is added to the allocation of the DB instance (1752). Further, the data allocation unit 382 adds a node set in the occupation 1762 of the DB instance.

Next, the data allocation unit 382 refers to the DB information 362 and confirms whether the DB instance sets a shared memory capacity and has a shareable management table. If there is free capacity in the node that secured the occupation management table, the data allocation unit 382 allocates the memory amount set in the shared memory capacity (1827) from the node. If the priority of the DB instance is high and there is no free capacity in the node that secures the occupancy management table, the data allocation unit 382 refers to the topology information 372 and the allocation information 364, and is closer to the node that secures the occupancy management table. The shared memory capacity is allocated preferentially from a certain unallocated node. If the priority of the DB instance is low and there is no free capacity in the node that secures the occupancy management table, the data allocation unit 382 refers to the topology information 372 and the allocation information 364 and is close to the node that secured the occupancy management table. A shared memory capacity is allocated from a node to which data of a DB instance having a low degree is allocated.

The data allocation unit 382 subtracts the secured shared memory size from the entire free area of the allocation information 364 (free GB 1708 of 1732 to 1740). Further, the secured shared memory size is added to the allocation of the DB instance (1752). Further, the data allocation unit 382 adds the node set in the sharing 1764 of the DB instance.

If there is a table to which the DB instance refers, and the DB instance to be referenced is already allocated, the data allocation unit 382 assigns the DB instance to the memory node used for sharing in the memory information of the allocated DB instance. Set the ID. When the DB instance 2 (330) shares the data of the DB instance 1 (300), 2 is set as the use instance ID of the share 1764.

When the DB instance uses partitioning, the data allocation unit 382 divides the allocation into a plurality of nodes when allocating the memory area of the table for partitioning when allocating the occupancy management table and the shareable management table. .

Step 915: The thread allocation unit 380 gives priority to the core on the node allocated in Step 910, and allocates the number of cores (1828, etc.) specified in the DB information 362 using the allocation information 364. If the number of free cores of the node allocated by the data allocation unit 382 in step 910 is less than the number of cores required by the DB instance, the thread allocation unit 380 refers to the distance 725 of the topology information 372 and allocates data. Select a node that is close to the node and assign the core to be used from there.

減らす Reduce the number of allocated cores from the number of nodes and the total number of free cores. Add to the assigned core of the DB instance.

Step 920: The database management thread 360 assigns and completely sets the status (1820, 1854) of the DB information 362 for the selected DB instance.

Step 925: The database management thread 360 refers to the DB information 362, and confirms whether or not the statuses of all the DB instances are completely assigned. If all DB instances have been assigned, the process proceeds to 930 and the assignment process is completed. If there is a DB instance that has not been assigned, the process returns to step 905.

The data allocating unit 382 and the thread allocating unit 380 realize the resource allocation considering the priority and the data sharing between the DB instances by allocating the memory and the core from the DB instance having the higher priority.

FIG. 11 shows an allocation example of DB instances sharing data in the embodiment. The memory used by the database management system 220 has a uniform capacity on each node (1305, 1320, 1335, 1350). The memory 1310 used for OLTP is secured from the memory 1 (112) of the node 1 (110) by the data allocation unit 382. The memory used for CRM is secured separately for the memory 2 (132) of the node 2 (130) and the memory 3 (152) of the node 3.

The core used in OLTP is a core that executes a high-priority thread, and is assigned to the

cores

118, 119, 120, and 121 of the node 1 (110) by the thread assignment unit 380 (1370, 1372, and 1374). 1376). The core used in CRM is a core that executes a low-priority thread, and is assigned to the

cores

138, 139, and 140 of the node 2 (130) (1380, 1382, and 1384).

In this way, when allocating a storage area or data processing for a high priority program such as OLTP, it is allocated to the memory or core of the same node as much as possible. When there is a shortage of memory or core, the data reference load is low. Allocate the core and memory of the node to be used.

Further, a memory or core for a program such as CRM that performs data processing using data for OLTP processes the same data by assigning it to a node adjacent to the node having the memory or core assigned for OLTP. Processing that does not unnecessarily increase the load of data reference / update between multiple programs becomes possible.

-Data used in both OLTP and CRM should be assigned to the node to which the high-priority OLTP data is assigned so that the load is not increased when OLTP processing is performed.

If the OLTP processing is allowed depending on the data capacity and the required number of cores, data and cores allocated for OLTP and CRM may coexist in some nodes.

If the data reference / update load is determined by referring to the topology information as shown in FIG. 6, it is possible to determine the load more accurately. However, the node numbers are assigned in ascending order of load or in descending order, and the node numbers are as close as possible. By selecting one, it is possible to provide a simple system that does not unnecessarily increase the load of data reference / update between programs sharing data.

FIG. 12 shows an allocation example of DB instances that do not share data in the embodiment.

The same type of application may be used, such as for OLTP, OLTP, CRM, and CRM, but it is difficult for the programs that do not need to share data to be affected by the load of data reference / update. Allocate memory and cores.

In this example, on the assumption that the node numbers are assigned in order of distance indicating the load of data reference / update, the data for OLTP, the cores are assigned in order from the node 1 to the node with the largest node number, and the data for CRM is the node number The effect is reduced by allocating nodes 4 having a larger node number to nodes having a smaller node number. You may allocate using topology information.

Even in this case, it is better to concentrate the memory and nodes allocated to one node as much as possible.

FIG. 13 is a conceptual diagram when a thread that performs transaction processing accesses data.

FIG. 13 shows customer information 318 that is a table shared by transaction thread 1 (302) of DB instance 1 (300) that processes OLTP and transaction thread 3 (332) of DB instance 2 (330) that processes CRM. It shows how to access.

The transaction thread (302, 332) holding each transaction (304, 334) accesses the customer information 318 using the access control unit 384 of the database management system 220. A transaction thread 1 (302) that executes the OLTP transaction 304 is a high-priority thread. The transaction thread 3 (332) that executes the CRM transaction 332 is a low-priority thread.

Customer information 318 stores customer data for each row of the table. The customer information 318 includes management information 1420 for managing the latest row data and actual data 1430 internally.

When the data of the customer information 318 is updated in the OLTP process, the transaction thread 302 generates update log information in the log buffer 1440. In the figure, update log information 1442 in which row 2 is changed is stored. The log generation unit 386 is executed by the transaction thread 1 (302) and the log management thread 1 (322), and stores the update log information in the secondary storage via the log buffer 1440.

In the CRM area, there is an update history 1450 that holds update log information of customer information 318. In the figure, update log information 1452 when row 1 is updated is stored. The memory management thread 320 and the memory management thread 350 can write the update information of the customer information 318 written in the log buffer 1442 periodically in the update history 1450 separately from the transaction processing. The access control information 1460 holds access frequency information between DB instances, the time when each DB instance last executed a transaction, the update time of referenced data, and the like.

The transaction thread (302, 332) and customer information (318) described in one node in the figure are arranged in a specific node, but the components described across other nodes are It does not matter where it is on the system.

FIG. 14 shows a processing flow of the access control unit.

Step 1500: The transaction thread requests the access control unit 384 to access data (read, write, etc.). The access control unit 384 starts specifying data to be accessed based on the request.

Step 1505: The access control unit 384 confirms whether the data is data shared with other DB instances from the requested data type. If the requested data type is a database table, it is determined by searching the occupancy management table (1836), sharable management tables (1842, 1844) and reference table (1846) of the DB information 362. can do.

In addition, even data other than tables can be determined by having information indicating whether sharing with other DB instances is possible as area management data. If the data is shared with other DB instances, the process proceeds to step 1510. If not shared, the management data and actual data are accessed (1610).

Step 1510: The access control unit 384 determines whether the transaction being executed is the owner of the requested data. For example, if the requested data is a table, whether or not it is the owner of the data is determined by whether or not there is information on the target table in the occupancy management table 1836 or the sharable management table 1842 of the DB information 362. Can do.

Also, as in step 1505, the determination can be made by registering the owner's DB instance ID in the area management data. If the transaction for accessing the data is the owner, the management data and the actual data are accessed (1610). If not, go to step 1515.

Step 1515: The access control unit 384 determines whether the priority of a DB instance having a transaction for accessing data is higher than the priority of other DB instances accessing the data. The priority of the DB instance that accesses data can be known by referring to the priority 1824 of the DB information 362, the management information of the transaction threads (302, 332), or the management information of the access data. As for the priorities of other DB instances, if the target data is a table, the DB information 362 is searched for a DB instance having a table in which the data exists in the reference table 1846, and the DB instance of the corresponding DB instance is searched. This can be known by referring to the priority 1824.

Alternatively, as management information of data to be accessed, a list of DB instances to be used and priorities are held, and the DB instance priority of a transaction accessing data is compared with the priorities of other DB instances. But it can be realized. If a DB instance that accesses data has a higher priority than other DB instances that are referred to, the management data and actual data are accessed (1610). Otherwise, go to step 1520.

Step 1520: The access control unit 384 determines whether the requested data access is an operation for newly writing or updating data. If it is write or update, the process proceeds to step 1525. If the operation is a reference only operation, the process proceeds to step 1540.

Step 1525: The access control unit 384 refers to the access control management information 1460, and confirms the frequency with which the DB instance executing the transaction can access the reference DB instance.

Step 1530: The access control unit 384 compares the accessible frequency obtained in step 1525 with the actual result and confirms whether or not the target is below the target. If it is below the target, the management data is accessed (1600).

Step 1535: The access control unit 384 performs the access process because the transaction is a transaction of a DB instance that does not hold the data to be referred to, and the DB instance frequently accesses the reference DB instance. Perform timing adjustment to delay.

For example, a sleep function is issued by the transaction thread so as to satisfy the target value, and another transaction process can be temporarily executed by executing a busy wait loop. The management data is accessed after the wait process (1600).

Step 1540: The access control unit 384 refers to the previous data or copied data that can be referred from the data update history, not the latest original data managed by the DB instance that owns the data, as the data reference of the transaction. Search if can see. Specifically, any or all of the following operations are performed to check whether there is target data, and the process proceeds to step 1545.

(1) A search is performed as to whether there is data to be accessed as an entry of the update history 1450 managed by the DB instance executing the transaction.

(2) Search for a change record of the data to be accessed in the log buffer held by the DB instance that manages the original data.

(3) Access the secondary storage device storing the DB instance log that manages the original data, and search for the updated log data of the accessed data in the latest log file.

Step 1545: If the data is found in Step 1540, the access control unit 384 proceeds to Step 1550. If not found, the process proceeds to step 1525.

Step 1550: The access control unit 384 obtains the difference between the current time and the update time of the found data. The access control unit 384 compares the obtained DB instance reference table / frequency information (such as 1846) of the DB information 362 with the obtained difference, and determines whether the freshness of the information is within the range. Further, the access control unit 384 compares the update time of the data referenced by the previously executed transaction stored in the access control management information 1460 with the update time of the found data, and the data in which the DB instance is found is valid. It is determined whether the data is within a certain range. If it is within the range, the old data is accessed (1625). If it is not within the range, the management data is accessed (1600).

In this embodiment, the determination method using time is shown, but the determination may be made using a transaction ID or a time stamp counter of the processor.

FIG. 15 shows the continuation of the processing flow of the access control unit.

Step 1610: The access control unit 384 determines access to the requested data as access to management data and actual data. When the transaction requests the data of the customer information 318, the management information 1420 and the actual data 1430 are accessed.

Step 1600: The access control unit 384 accesses the requested actual data. When the transaction requests the data of the customer information 318, a process for referring to the management information 1420 is performed.

Step 1605: The access control unit 384 refers to the management information and determines whether or not the transaction can currently operate the requested data. For example, it is confirmed whether or not a lock flag is set. If it can be operated, the process proceeds to Step 1615. If it cannot be operated, the process proceeds to step 1620.

Step 1615: The access control unit 384 determines that the transaction accesses the latest actual data of the requested data. When the transaction requests the data of the customer information 318, the actual data 1430 is accessed.

Step 1620: The access control unit 384 determines that the transaction accesses the latest actual data of the requested data. However, since the data is used by other transactions, the data is not accessed immediately, but is registered after waiting for the lock to be released.

Step 1625: The access control unit 384 determines that the transaction accesses the old data searched in Step 1540. When the transaction requests row 1 of the customer information 318, the entry 1542 of the update history 1450 is used. When the transaction requests line 2 of the customer information 318, the entry 1442 of the log buffer 1440 is used. If it exists in the log file, the log file data is used.

In the present embodiment, an example in which freshness is specified in a setting file (DB instance definition file) is shown. As a method for designating the freshness, the database management system 220 can also be added to a query statement (SQL) using a command interface.

101 server, 200 memory, 270 processor, 220 database management system, 260 operating system, 300

DB instance

1, 330

DB instance

2, 360 database management thread, 362 DB information, 364 allocation information, 370 topology management thread, 372 topology information, 380 thread allocation unit, 382 data allocation unit, 384 access control unit, 386 log generation unit, 400 database management system configuration information, 500 DB instance definition file, 600 DB instance definition file

Claims

A computer system composed of a plurality of processors,
The processor includes a plurality of cores and a memory,
A thread allocation unit that allocates a thread that executes an application program to the core;
A data allocation unit that allocates data used in the application to a memory;
The thread allocation unit allocates a high priority thread that is a thread that executes an application with a high priority and a low priority thread that is a thread that executes an application with a low priority to different processor cores,
The data allocation unit performs data allocation so as to store common data accessed by both the high priority thread and the low priority thread in a memory associated with a processor to which the high priority thread is allocated. A computer system.
The computer system according to claim 1,
The computer system according to claim 1, wherein the thread allocation unit allocates a high priority thread for executing a single application to a core of a single processor if possible.
The computer system according to claim 1,
When the low-priority thread accesses common data stored in the memory of the processor to which the high-priority thread is allocated, the low-priority thread includes an interface that specifies how often the low-priority thread accesses the common data. Computer system.
The computer system according to claim 1,
When the low priority thread accesses the common data stored in the memory of the processor to which the high priority thread is allocated, the low priority thread includes an access control unit that controls the frequency with which the low priority thread accesses the common data. A computer system.
The computer system according to claim 1,
A log creation unit that creates an update log when a high priority thread updates common data and stores it in the memory of the processor to which the high priority thread is assigned,
A computer system characterized in that a low priority thread refers to the update log.
The computer system according to claim 5,
The update log is a database log, which is output from a processor memory to an external storage device based on a predetermined rule,
A computer system, wherein a low priority thread refers to the output log.
The computer system according to claim 5,
The access control unit accesses the common data stored in the memory of the processor to which the high priority thread is allocated or accesses the update log based on the time when the common data accessed by the low priority thread is updated. A computer system characterized by controlling the above.
In the computer system according to claim 7,
The computer system according to claim 1, wherein the high-priority application is an online transaction program, and the low-priority application is a customer relationship management program.
When a thread allocation unit allocates a thread that executes an application program to a core of a processor having multiple cores, a thread that executes a high priority thread that is a thread that executes a high priority application and a thread that executes a low priority application Assign low priority threads to different processor cores,
When the data allocation unit allocates the data used in the application to the memory, the data allocation unit stores the common data accessed by both the high priority thread and the low priority thread to the memory of the processor to which the high priority thread is allocated. A computer system management method characterized by assigning.
In the computer system management method according to claim 9,
The computer system management method according to claim 1, wherein the thread allocation unit allocates a high priority thread for executing a single application to a core of a single processor if possible.
In the computer system management method according to claim 9,
When the low priority thread accesses the common data stored in the memory of the processor to which the high priority thread is allocated, the computer management method is characterized by specifying the frequency with which the low priority thread accesses the common data. .
In the computer system management method according to claim 9,
When the low priority thread accesses the common data stored in the memory of the processor to which the high priority thread is allocated, the access control unit controls the frequency with which the low priority thread accesses the common data. Computer management method to do.
In the computer system management method according to claim 9,
The log creation unit creates an update log when the high priority thread updates common data, stores it in the memory of the processor to which the high priority thread is assigned,
A computer management method, wherein a low priority thread refers to the update log.
In the computer management method according to claim 13,
The update log is a database log, which is output from a processor memory to an external storage device based on a predetermined rule,
A computer management method, wherein the low priority thread refers to the output log.
In the computer management method according to claim 13,
The access control unit accesses the common data stored in the memory of the processor to which the high priority thread is allocated or accesses the update log based on the time when the common data accessed by the low priority thread is updated. A computer management method characterized by controlling the above.