?? readme.htm
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.ord/TR/html4/loose.dtd"><html><head><title>eXtremeDB 3.0 Release Notes</title><meta name="description" content="eXtremeDB 2.3 Installation and Release Notes"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body bgcolor="#ffffff" text="#000000"><h2><a name="id1"><i>e</i>X<i>treme</i>DB<sup>™ </sup>3.0 from McObject<sup>®</sup></a></h2> <h3><a name="id5">Release Notes</a></h3> <table><tr> <td><b>Target OS</b>:</td> <td>Linux</td></tr><tr> <td><b>Host OS<sup></b>:</td> <td> Linux (x86)</td></tr></table><hr><table><td><b>BY USING THIS SOFTWARE YOU AGREE TO McObject's <a href="./License.txt">LICENSE AGREEMENT</b></a> </td></table><hr><ul><h2><a name="#BUILDING">Build procedures</a></h2> <p><b>Building the runtime and samples (source-code license only)</b></p> <p><br>Your distribution package contains a number of pre-built runtime libraries installed into the target/bin directory. This readme file outlines the聽purpose of each library (see What's included in this package section). Each runtime library in the target/bin directory is built with some particular options set. For example, the libmcolib_log.a represents a core runtime library that includes transaction logging support, while the libmcolib.a does not include the transaction logging support. Each of the pre-built binaries correspond to a set of options defined in the include/mcocfg.h file. For instance, the transaction logging support is turned on by the following define:<br> </p><p><b>#define MCO_CFG_LOG_SUPPORT</b><br> <br>You may build the eXtremeDB samples using the preinstalled schema compiler and pre-built libraries simply by executing 'make' from the root installation directory. If you decide to rebuild all binaries, please use the following make options:<br> <br>$ make<br> or<br>$ make samples - to build or rebuild sample applications<br> $ make tools -聽to build mcocomp, pickmem, sql2mco and libraries<br> $ make all - to build samples and tools<br> $ make clean -聽to remove all temporary and intermediate files<br> $ make distclean - to remove all binary, temporary and intermediate files<br> <br>The make script will build the DDL schema compiler (mcocomp), the tools (pickmem), the runtime libraries (libmcolib*, libmcoxml*,libmcolog*) and put them into the host/bin and target/bin directories respectively. <br> The make script will build the entire set of binaries regardless of the settings in the include/mcocfg.h file. If you wish to build an individual runtime with some particular set of options, you may do so by allowing (defining) the runtime options that you wish to build the runtime with in the mcocfg.h file and running 'make' from the target/mcolib directory. For example, you may #define MCO_CFG_LOG_SUPPORT and聽run 'make'. This will result in building three libraries: <br> </p><p> libmcolib.a -- core runtime with TL support <br> libmcolog.a -- the actual transaction logging <br> libmcoxml.a -- xml extensions<br> <br>To build the debug version of the samples, you may edit the include/header.mak file, and remove the comment from the following line:<br> </p><code> <p><b>DEBUG=on</b></p></code><p><br>or simply type 'make DEBUG=on' instead of 'make'<br> <br><b>Object-only installations:</b><br> For object-only installations, the runtime is pre-built and installed into the target/bin directory. To build all the samples, run make from the root installation directory.<br> <br><b>Building the DDL compiler.</b> This package contains native x86 Linux and Microsoft Windows versions of the eXtremeDB DDL compiler. They are located in the <i>host/bin</i> directory. It is not necessary to re-build the compiler. However, if you decide to do so, please run <i>'make tools'</i>. Please note that g++ version 3.0.2 of higher is required to build the Linux version of the compiler. In order to rebuild the Microsoft Windows version of the compiler, please contact our technical support department.</p> <h2><a name="#PERFORMANCE">Performance optimizations</a></h2><b>Database runtime locking.</b> The runtime implements a number of latches to synchronize the access to the runtime heap, transaction queue and registry from multiple threads. Although better parallelism is achieved with multiple latches, the overhead of applying the locks could bring the overall performance down. The number of latches used by the runtime can be configured at compile time in four ways. <ul> <li>multiple latches (locks) for the transaction queue, separate locks for the heap and the registry. This option is best for applications with many concurrent threads running on multiple CPUs.</li> <li>one lock for the transaction queue, separate locks for other internals. Usually best in a single CPU environment.</li> <li>one latch to lock the entire runtime. Usually best with a low number of simultaneous threads.</li> <li>no locks at all. (Single thread mode.)</li></ul>By default the runtime is configured with the fully serialized transaction queue, but separate latches for the registry and the runtime heap (the second option described above). If your application would benefit from another configuration option, define the appropriate serialization method in the <i>mcocfg.h</i> files and rebuild the runtime. If the source code is not available, please contact technical support for assistance. <br><br><b>Synchronization primitives</b>. eXtremeDB implements its own latches to synchronize access to the runtime internals from multiple simultaneous threads or processes. These user-level latches are based on the synchronization primitives provided by the OS. The runtime can be configured to use two different Linux primitives as a basis for latch implementation: <ul> <li>POSIX standard process/thread synchronization and communication services via POSIX semaphores</li> <li>Linux spinlocks</ul>Usually, the best performance is exhibited with the spinlock-based implementation of latches. Therefore, by default the runtime is configured to use spinlocks approach as the basis for the latch implementation. If your application would benefit from using the POSIX-based approach please contact us for assistance. <br><br><b>Runtime build options.</b> The eXtremeDB runtime library is built with the -O4 option, - thus it is optimized for speed. If you have access to the eXtremeDB source code, for x86 platforms it is possible to further optimize the runtime performance by rebuilding the runtime library with Intel compiler. You can download a free copy from the Intel web site: <ul> <a href="http://www.intel.com/software/products/compilers/clin/noncom.htm"> <tt>http://www.intel.com/software/products/compilers/clin/noncom.htm</tt></a></ul>Once you have installed it, change the makefiles from using GCC to ICC. Depending on the CPU, you may use different optimization options. For example, the following optimization options are used to optimize the code for Pentium 4: <ul> <code><p>"-xW -O3 -ipo -ipo_obj"</p></code></ul> the <b>-xW</b> produces code that only runs on a Pentium 4, use <b>-xM</b> for Pentium II code. Please consult Intel documentation for further information. <br> In order to optimize the runtime size (footprint), it can be built with the -Os option. It is also possible to compile out features that your application will not require, such as history support, save/load support, etc. If you need assistance to make further optimizations please contact our <a href="mailto:support@mcobject.com"><tt>technical support</tt></a> department. <h2><a name="#ST">Single Threaded version</a></h2>eXtremeDB is available in a Single-Threaded edition (eXtremeDB-ST). eXtremeDB-ST is a version of eXtremeDB, that only permits the runtime to be accessed from a single thread. Since eXtremeDB-ST does not need to coordinate access from multiple threads, no locks are applied (see <a href="#PERFORMANCE">Performance Optimizations</a> section above). <br><br>The following options cannot be combined with the ST edition: <ul> <li> <a href="#HA">High Availability</a> option </li> <li> XML support </li> <li> Shared Memory option </li></ul> <h2><a name="#SHMEM">Shared-memory version issues</a></h2><b>Synchronous events</b> handles must be used only from the process that has registered the event. The runtime does not verify the process that calls the event handler, thus an access violation will occur. <br><br><b>Setting the eXtremeDB shared memory pool.</b>When a shared memory database is created, the eXtremeDB runtime allocates two shared memory segments: one for the eXtremeDB "registry" that keeps information about all database instances created on the machine and another segment for the data repository itself. Linux shared memory segments are implemented via the System V IPC mechanism. System V IPC methods are associated with system-wide integers, called keys which are associated with files. By default, the files associated with the keys created by the eXtremeDB runtime are places into the <b>HOME</b> directory. You may, however, overwrite this setting by setting the environment variable <b>EXTREMDB_DIR</b>. <ul><code><p>export <b>EXTREMEDB_DIR= path</b></p></code></ul>Linux is often configured with defaults for shared memory parameters which may not be enough for larger databases. The default shared memory limit <b>SHMMAX</b>, is usually 32 MB in 2.x kernels, but it can be changed in the proc system file (without reboot).<br> For example, to allow 128 MB: <ul><code><p>$ echo 134217728 >/proc/sys/kernel/shmmax</p></code></ul>You could put these commands into a script run at boot-time.<br> Alternatively, you can use sysctl, if available, to control these parameters. Look for a file called /etc/sysctl.conf and add lines like the following to it: <ul><code><p>kernel.shmmax = 134217728</code></p></ul>This file is usually processed at boot time, but sysctl can also be called explicitly later. <br><br> <b>Debugging shared memory databases initialization and shutdown. </b>Sometimes, during development, it is useful to observe how the shared segments are being created and destroyed. This is done by setting the environment variable <b>MCO_DEBUG_PRT</b>: <ul><code><p>export <b>MCO_DEBUG_PRT=1</b></code></p></ul><b>Cleaning-up orphaned shared memory segments.</b> If the process is interrupted before the database is removed, the memory segments remain allocated. Please remove them manually using the ipcrm command. The following sample illustrates this process: <ul><code><p>$ ipcs<br>------ Shared Memory Segments --------<br>key shmid owner perms bytes nattch status<br>0x00000000 65536 gdm 777 196608 2 dest<br>0x00000000 131073 gdm 777 196608 2 dest<br>0x0102c596 884738 root 666 1024 0<br>0x0302c596 950275 root 666 16384000 0<br><br>------ Semaphore Arrays --------<br>key semid owner perms nsems status<br><br>------ Message Queues --------<br>key msqid owner perms used-bytes messages<br><br>$ ipcrm shm 884738<br>resource(s) deleted<br>$ ipcrm shm 950275<br>resource(s) deleted<br></code></p></ul> <h2><a name="Transaction Logging">Transaction Logging</a></h2> <p>Starting with the version 2.3 eXtremeDB adds an ability to log the database transaction to a persistent storage media such as a hard disk. Transaction Logging facilitates the durability of the eXtremeDB in-memory databases by providing the Transaction Log API. In the TL-enabled version of the eXtremeDB, every update action of a transaction is recorded in the in-memory buffers. Upon the transaction commit these buffers are appended to the <i>database log files</i>. No records are added to the log if the transaction is read-only. For recovery the log is read backwards. To avoid a complete backwards scan during recovery a mechanism called 鈥渃heckpointing鈥?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -