跳到主要內容

MySQL Virtualization Performance Issues

Often the biggest consideration is the performance of a virtualized environment once hosted. In most cases, the virtualized environment involves some level of emulation of one or more of the hardware interfaces (CPU, network or disk) of the host environment. The effect is to reduce the effective performance of the virtualized environment compared to running an application natively on the host.
Some core resourcing issues to be aware of include:

•Using virtualization does not reduce the amount of CPU required to support a particular application or environment. If your application stack requires 2GB of RAM on an individual machine, the same RAM requirement will apply within your virtualized environment. The additional overhead of the virtualization layer and host operating system or environment often mean that you will need 2.5GB or 3GB of RAM to run the same application within the virtualized environment.
You should configure your virtualization environment with the correct RAM allocation according to your applications needs, and not to maximize the number of virtualized environments that you can execute within the virtualization host.


•Virtualization of the CPU resources is more complex. If your MySQL database and application stack do not have a high CPU load, then consolidating multiple environments onto a single host is often more efficient. You should keep in mind that at peak times your application and database CPU requirement may need to grow beyond your default allocation.
With some virtualization environments (Xen, Solaris Containers, Solaris LDOMs) you can dedicate CPU or core to a virtual instance. You should use this functionality to improve performance for database or application loads that have a high constant CPU requirement as the performance benefit will outweigh the flexibility of dynamic allocation of the CPU resources.


•Contention of resources within the host should be taken into account. In a system with high CPU loads, even when dedicating RAM and CPU resources, the I/O channels and interfaces to storage and networking resources may exceed the capacity of the host. Solutions such as Xen and Solaris LDOMs dedicate specific resources to individual virtual instances, but this will not eliminate the effects of the overall load on the host.


•If your database application is time sensitive, including logging and real-time database applications, or you are using MySQL Cluster, then the effects of virtualization may severely reduce the performance of your application. Because of the way the virtualized instances are executed and shared between CPUs and the effects of load on other resources, the response times for your database or application may be much higher than normal. This is especially true if you are running a large number of virtualized instances on a single host.


•Be aware of the limitation of using a single host to run multiple virtualized instances. In the event of a machine or component failure, the problem will affect more than just one database instance. For example, a failure in a storage device could bring down all your virtualized instances. Using a RAID solution that supports fault tolerance (RAID levels 1,3,4,5 or 6) will help protect you from the effects of this.

留言

這個網誌中的熱門文章

Window CE BootLoader for x86 ( MS-DOS )

CEPC X86採用了幾種開機方式,其中一種運用MS-DOS當成Booting OS 利用 Windows CE Platform builder所提供的 Image disk 製作一片 1.44M的開機片,內有提供 LoadCepc.exe命令作為 CE Boot Loader 不過首先得先將磁片的開機檔案移植到嵌入式設備的CF / FLASH / DISK 上 以下提供傳統的MS-DOS開機系統製作方式供學員參考 : 使用MS-DOS開機片開機後, 透過 Fdisk.exe與 Format.com 工具製作 Windows CE Boot Loader 過程如下 圖一: MS-DOS開機 圖2: 開機後,載入 Fdisk執行 Partition切割工作 圖3: 選擇第一項,建立 Partition 圖4: 選擇第一項,建立 DOS Partition 圖5: 詢問是否全部切割成單一PARTITION,若CF過大可回答 N 自行切割大小 圖6: 輸入欲切割的Partition大小 圖7:切割後,按一下鍵盤的 esc鍵回到檢視畫面,就可看到所切割的Partition大小 圖8: esc回到主選單後,在選擇 [2] 設定啟動磁區 圖9: 選擇欲啟動作業系統的Partition 圖10: 選擇後應該會看到 Partition清單上的 Status欄位出現 A 字元 圖11: 切割後 重新啟動系統 圖12: 格式化所切割的新磁區 圖13: 格式化完成後 便可將 Platform Builder所製作的 Windows CE Bootloader磁片內容複製到C:內 重新開機後,進入c:> 輸入 C:>Loadcepc /L:800x600x16 nk.bin 便可載入nk.bin到記憶體 並且以800x600的解析度執行 windows ce 作業系統

Windows CE 必備工具--DiskPrep

Windows CE image 建置完畢欲部署到裝置上執行之前,前置工作就是提供一個可開機的環境讓nk.bin能順利載入,Windows ce device上面 無論是使用 Hard Disk , USB Flash , CF 任何bootable storage都能透過 DiskPrep.exe 工具在 Storage Devices上面製作 Biosloader 提供 image 安裝與執行的能力 載點如下 http://archive.msdn.microsoft.com/DiskPrep

如何以 Offline 方式檢查 Image 的 Registry

當我們需要維護一個已經部署好的XPE Device,我們可能必須得知一個 XPE image內的Registry 設定 若該device基於安全理由並未提供內建的Registry Editor工具, 我們可以採用 Offline的方式檢閱或是編輯該device 的Registry,方式如下: 1. 開啟 Registry Editor工具 2. 點選欲編輯的Hive: HKEY_USERS or HKEY_LOCAL_MACHINE 3. 載入 Device 的Registry Config File 通常Registry File位於 Offline run-time image內的 \Windows\System32\Config資料夾內 4.載入後,給予載入的 Hive一個任意指定的 Keyname 後便完成離線的Registry 載入工作 透過上述的步驟便可以將device的Registry掛載到目前的 registry editor並從中了解device的相關配置或是更新QFE的相關資訊