menembus batas impian

How to install Canon LBP-2900 on Linux (Centos 6.2)
For Local Printer

Get Driver for your Canon LBP-2900 driver on

Download CAPT Printer Driver for Linux Version 2.50

# wget

Extract it

# tar -zxvf Linux_CAPT_PrinterDriver_V250_uk_EN.tar.gz

Install only 2 files
# rpm -Uvh Linux_CAPT_PrinterDriver_V250_uk_EN/32-bit_Driver/RPM/cndrvcups-common-2.50-1.i386.rpm

# rpm -Uvh Linux_CAPT_PrinterDriver_V250_uk_EN/32-bit_Driver/RPM/cndrvcups-capt-2.50-1.i386.rpm

Restart the cups

/etc/init.d/cups restart

Now run this command

# /usr/sbin/lpadmin -p LBP2900 -m CNCUPSLBP2900CAPTK.ppd -v ccp:/var/ccpd/fifo0 -E
# /usr/sbin/ccpdadmin -p LBP2900 -o /dev/usb/lp0









Start ccpd service

/etc/init.d/ccpd start

To see printer status

# captstatusui -P LBP2900

For Network Printer

Simple, just add printer using smb connection and CAPT driver from canon which you can find on /usr/share/cups/model/ and for Canon LBP-2900 you can using /usr/share/cups/model/CNCUPSLBP2900CAPTK.ppd And Here is my printers.conf

Info Canon LBP2900 CAPT English
Location Titan
MakeModel Canon LBP2900 CAPT ver.1.5
DeviceURI smb://username:password@
State Idle
StateTime 1367827711
Type 8392836
Filter application/vnd.cups-raw 0 –
Filter application/vnd.cups-postscript 0 pstocapt
Filter application/vnd.cups-command 0 commandtops
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer


snapshot3Image 3








kopas :



VLC (VideoLAN Client) is an open source and free simple fast and much powerful cross-platform player and framework for playing most of multimedia files like CD, DVD, VCD, Audio CD and other various supported streaming media protocols. It was written by the VideoLAN project and can be available for all operating platforms such as Windows, Linux, Solaris, OS X, Android, iOS and other supported operating systems.

It also has compression feature for many audio and video files and ability to stream media files over computer network. For more information and features can be found at

In this new series of Linux Players, we will show you how to install latest version of VLC Media Player in RHEL 6.3/6.2/6.1/6/5.8/5.6, CentOS 6.3/6.2/6.1/6/5.8/5.6 and Fedora 17,16,15,14,13,12 systems using third party repositories with Yum automated package installer.

Install EPEL, Remi and RPMFusion Repositories in RHEL/CentOS/Fedora

VLC program doesn’t included in the Linux operating systems, we need to install it using third party repositories like Epel, Remi and RPMFusion. With the help of these repositories we can install list of all updated packages automatically using YUM package manager tool.

Installing EPEL & Remi Repository in RHEL/CentOS

First, install Epel and Remi repository for your Linux OS distribution using following links. Please select and install it according to your Linux supported system versions.

For RHEL/CentOS 6.3/6.2/6.1/6.0
# yum localinstall --nogpgcheck
# yum localinstall --nogpgcheck
For RHEL/CentOS 5.8/5.6/5.0
# yum localinstall --nogpgcheck
# yum localinstall --nogpgcheck

Installing RPMFusion Repository in RHEL/CentOS/Fedora

You also need to install RPMFusion repository too, under your Linux system. So, please choose and install as per your system supported version.

For RHEL/CentOS 6.3/6.2/6.1/6.0
# yum localinstall --nogpgcheck
# yum localinstall --nogpgcheck
For RHEL/CentOS 5.8/5.6/5.0
# yum localinstall --nogpgcheck
# yum localinstall --nogpgcheck
For Fedora 17/16/15/14/13/12
# yum localinstall --nogpgcheck 
# yum localinstall --nogpgcheck

Check the Availability of VLC in RHEL/CentOS/Fedora

Once you’ve all the repositories installed on your system, do the following command to check the availability of VLC player.

## Under RHEL/CentOS 6/5 ##
# yum --enablerepo=remi-test info vlc

## Under Fedora 17/16/15/14/13/12 ##
# yum --enablerepo=remi info vlc
Sample Output :
Loaded plugins: fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
Available Packages
Name        : vlc
Arch        : i686
Version     : 2.0.3
Release     : 1.el6
Size        : 1.9 M
Repo        : rpmfusion-free-updates
Summary     : The cross-platform open-source multimedia framework, player and server
URL         :
License     : GPLv2+
Description : VLC media player is a highly portable multimedia player and multimedia framework
            : capable of reading most audio and video formats as well as DVDs, Audio CDs VCDs,
            : and various streaming protocols.
            : It can also be used as a media converter or a server to stream in uni-cast or
            : multi-cast in IPv4 or IPv6 on networks.

Installing VLC Player in RHEL/CentOS/Fedora

As you see the VLC player is available, so install it by running the following command on the terminal.

## Under RHEL/CentOS 6/5 ##
# yum --enablerepo=remi-test install vlc

## Under Fedora 17/16/15/14/13/12 ##
# yum --enablerepo=remi install vlc

Starting VLC Player in RHEL/CentOS/Fedora

Run the following command from the Desktop terminal as normal user to Launch the VLC player. (Note : VLC is not supposed to be run as root user).

$ vlc
VLC Player Preview

See the preview of VLC Player under my CentOS 6.3 system.

Updating VLC Player in RHEL/CentOS/Fedora

If you would like to Update or Upgrade VLC player to latest stable version, use the following command.

## Under RHEL/CentOS 6/5 ##
# yum --enablerepo=remi-test update vlc

## Under Fedora 17/16/15/14/13/12 ##
# yum --enablerepo=remi update vlc

JAVA is one of popular programming language today. Made by Sun Microsystem, and later bought by Oracle. However, JAVA programming language is restricted so most linux distribution not include it. This article will discuss about installing latest JAVA 7 (January 15th, 2013) to Slackware Linux 64 bit.
What we need:
Slackware 64 bit, version 14.0
Oracle’s JRE or JDK
SlackBuild script
The Latest JAVA version per January 15th 2013 would be Java 7u11. You can download the binary from here. Decide what you want to install, either the JDK or JRE but not both. If you are developing application for JAVA, use JDK instead of JRE. Use JRE if you only want to run some application but not developing one. Thus, JDK might be safe choice for you.
If you want to install Oracle JRE you may download the jre-7u11-linux-x64.tar.gz. The JDK version would be jdk-7u11-linux-x64.tar.gz. Be sure you have accept the license agreement otherwise you can’t download it. And remember to download only the .tar.gz version to follow this article.
Now, download the slackbuild script. You can visit here. Actually you can read the README file but let this article be your only source hahaha ^^.
Update 2: There’s now a script that can repackage Oracle’s JRE or JDK into a Slackware package here (64-bit here). Just follow the instructions in the README file. Again, here is some information about installing OpenJDK.
What you must download:
slack-desc.jdk or slack-desc.jre (depend on what you want to install)
some script on profile.d/
Now, download all the required material and place in on same directory. Let say /tmp/java
execute the slackbuild script by invoking
/bin/sh java.SlackBuild
Wait until the process finished and you will get a new installation file on /tmp. Install it by invoking (for JDK):
upgradepkg –install-new /tmp/jdk-7u11-x86_64-1.txz
If you want to install JRE you would get jre one, so install it by invoking:
upgradepkg –install-new /tmp/jre-7u11-x86_64-1.txz
Congratulations! You have successfully install Java to your system. But wait, it’s not finished yet.
Our installation would be on /usr/lib64/java directory so we must update our environment variable so the system can find the JAVA. If you are using bash you can edit ~/.bashrc using nano or vi and add this snippet in the end of your file (or you must create new one if you don’t have any)
export JAVA_HOME=/usr/lib64/java export PATH=”${PATH}:${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin” export MANPATH=”${MANPATH}:${JAVA_HOME}/man”
Now reopen your shell and type java.

[root@localhost pabhe]# rm -rf /var/lib/mysql/mysql.sock
[root@localhost pabhe]# service mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
[root@localhost pabhe]#

Step 1: Installing Dependency Packages

We need to install ‘Development Tools‘ with some core development tools such gcc, flex, bison, debuggers etc. these software’s are must required to compile and build new packages, install them using YUM command.

# yum -y groupinstall ‘Development Tools’
# yum -y install libX11-devel freetype-devel

Step 2: Downloading Wine 1.6

Download the source file using Wget command under /tmp directory as a normal User.

$ cd /tmp
$ wget

Step 3: Extracting Wine 6

Once the file is downloaded under /tmp directory, use the below commands to extract it.

$ tar -xvf wine-1.6.tar.bz2 -C /tmp/

Step 4: Installing Wine 1.6

It is recommended to compile and build Wine installer as a normal User. Run the following commands as normal user. (Note : The installer might take up-to 20-30 minutes and in the middle it will ask you to enter root password).
On 32-Bit Systems

$ cd wine-1.6/
$ ./tools/wineinstall

On 64-Bit Systems

$ ./configure –enable-win64
$ make
# make install

Once the installation completes run the “winecfg” configuration tool from KDE or GNOME desktop to see the supported configuration. If you don’t have any of the desktop, you can install it by using the below command as root user.

# yum groupinstall “X Window System” “GNOME Desktop Environment”
# yum groupinstall “X Window System” “KDE (K Desktop Environment)”

Once the X Window System installed, run the command as normal user to see wine configuration.

$ winecfg

Jika Anda sudah membaca cukup forum yang terkait database milis atau blog Anda mungkin pernah mendengar mengeluh tentang MySQL tidak mampu menangani lebih dari 1.000.000 (atau pilih nomor lain) baris oleh beberapa pengguna. Di sisi lain hal ini juga diketahui dengan pelanggan seperti Google, Yahoo, LiveJournal, Technocarati MySQL memiliki instalasi dengan banyak miliaran baris dan memberikan performa yang hebat. Apa yang bisa menjadi alasan? Alasannya biasanya desain meja dan memahami karya batin MySQL. Jika Anda merancang data Anda dengan bijaksana mempertimbangkan apa MySQL dapat lakukan dan apa yang tidak bisa Anda akan mendapatkan kinerja besar jika tidak, Anda mungkin menjadi marah dan menjadi salah satu blogger thouse. Catatan – sistem manajemen database yang berbeda dalam beberapa hal dan apa yang bekerja dengan baik untuk Oracle, MS SQL, PostgreSQL mungkin tidak bekerja dengan baik untuk MySQL dan sebaliknya. Bahkan mesin penyimpanan memiliki perbedaan yang sangat penting yang dapat mempengaruhi kinerja secara dramatis. Tiga isu utama yang harus diperhatikan jika Anda sedang berhadapan dengan set data yang sangat besar adalah Buffer, Indeks dan Bergabung. Buffer Hal pertama yang Anda perlu mempertimbangkan adalah fakta – Situasi saat data cocok di memori dan ketika itu tidak sangat berbeda. Jika Anda mulai dari ukuran data di memori dan mengharapkan penurunan kinerja bertahap sebagai ukuran basis data tumbuh Anda mungkin akan terkejut dengan penurunan melayani dalam kinerja. Hal ini terutama apel ke lookus indeks dan bergabung yang kita membahas nanti. Seperti segala sesuatu yang biasanya memperlambat banyak sekali tidak cocok dalam memori solusi yang baik adalah untuk memastikan data Anda cocok di memori sebaik mungkin. Hal ini bisa dilakukan dengan data partisi (yaitu data lama dan jarang diakses disimpan dalam server yang berbeda), multi-server partisi menggunakan gabungan memori dan banyak lainnya teknik yang harus saya menutupi pada beberapa waktu kemudian. Jadi, Anda mengerti berapa banyak memiliki data dalam memori mengubah hal-hal di sini adalah contoh kecil dengan angka. Jika Anda memiliki data Anda sepenuhnya dalam memori Anda bisa melakukan lebih dari 300.000 dari pencarian acak per detik dari thread tunggal tergantung pada sistem dan struktur tabel. Sekarang jika Anda Data sepenuhnya pada disk (baik data dan indeks), Anda akan membutuhkan 2 + IOS untuk mengambil baris yang berarti Anda mendapatkan sekitar 100 baris / detik. Perhatikan beberapa drive tidak benar-benar banyak membantu karena kita berbicara tentang thread tunggal / query sini. Jadi perbedaan adalah 3.000 kali! Mungkin agak terlalu banyak karena ada beberapa beban kerja sepenuhnya uncached tapi 100 + kali perbedaan adalah cukup sering. Indeks Apa semua orang tahu tentang indeks adalah fakta bahwa mereka baik untuk mempercepat akses ke database. Beberapa orang juga akan ingat jika indeks membantu atau tidak tergantung pada indeks selektivitas – bagaimana sebagian besar baris sesuai dengan nilai indeks tertentu atau jangkauan. Apa yang sering dilupakan adalah tentang – tergantung jika beban kerja cache atau tidak selektivitas yang berbeda mungkin menunjukkan manfaat dari menggunakan indeks. Bahkan bahkan MySQL optimizer saat ini tidak memperhitungkannya. Untuk Dalam memori beban kerja akses indeks mungkin akan lebih cepat bahkan jika 50% dari baris yang diakses, sedangkan untuk IO disk terikat accessess kita mungkin lebih baik melakukan meja penuh memindai meskipun hanya beberapa persen atau baris yang diakses. Mari kita melakukan beberapa perhitungan lagi. Pertimbangkan tabel yang memiliki 100 baris byte. Dengan SCSI drive yang layak kita bisa mendapatkan 100MB/sec kecepatan baca yang memberi kami sekitar 1.000.000 baris per detik untuk akses sepenuhnya berurutan, selai dikemas baris – skenario sangat mungkin untuk tabel MyISAM. Sekarang jika kita mengambil hard drive yang sama untuk sepenuhnya beban kerja IO terikat akan mampu menyediakan hanya 100 baris pencarian dengan indeks pr kedua. Perbedaannya adalah 10.000 kali untuk skenario kasus buruk kami. Mungkin tidak terlalu buruk dalam praktek tapi sekali lagi itu tidak sulit untuk mencapai 100 kali perbedaan. Berikut ini adalah sedikit ilustrasi saya buat meja dengan lebih dari 30 juta baris. “Val” kolom dalam tabel ini memiliki 10000 nilai yang berbeda, sehingga rentang 1 .. 100 memilih sekitar 1% dari tabel. Waktu untuk meja penuh memindai vs rentang scan dengan indeks: Tempurung mysql> select count(pad) from large; +————+ | count(pad) | +————+ | 31457280 | +————+ 1 row in set (4 min 58.63 sec) mysql> select count(pad) from large where val between 1 and 100; +————+ | count(pad) | +————+ | 314008 | +————+ 1 row in set (29 min 53.01 sec) mysql> select count (pad) dari besar; + ———— + | count (pad) | + ———— + | 31.457.280 | + – ———- + 1 baris dalam set (4 min 58.63 sec) mysql> select count (pad) dari besar mana val antara 1 dan 100; + ———— + | count (pad) | + ———— + | 314008 | + ———— + 1 row in set (29 min 53,01 detik) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 mysql> pilih count (pad) dari besar; + ———— + | count (pad) | + ———— + | 31457280 | + ———— + 1 baris dalam mengatur (4 min 58,63 sec) mysql> pilih count (pad) dari besar mana val antara 1 dan 100; + ———— + | count (pad) | + ———— + | 314.008 | + ———— + 1 baris dalam mengatur (29 min 53,01 sec) Juga ingat – tidak semua indeks diciptakan sama. Beberapa indeks dapat ditempatkan di halaman ditempatkan di tempat-tempat acak cara diurutkan atau – hal ini dapat mempengaruhi indeks scan / rentang kecepatan scan secara dramatis. Baris direferensikan oleh indeks juga bisa ditemukan secara berurutan atau memerlukan Radom IO jika rentang indeks scan. Ada juga tombol berkerumun di InnoDB yang menggabungkan akses indeks dengan akses data, menghemat IO untuk sepenuhnya beban kerja disk yang terikat. Ada optimasi tertentu dalam karya-karya yang akan meningkatkan kinerja indeks akses / index scan. Misalnya mengambil nilai indeks pertama dan kemudian mengakses baris dalam urutan diurutkan dapat banyak bantuan untuk scan besar. Hal ini akan mengurangi kesenjangan tapi aku ragu itu akan ditutup. Bergabung Bergabung digunakan untuk menyusun obyek yang kompleks yang sebelumnya dinormalisasi ke beberapa tabel atau melakukan query kompleks menemukan hubungan antara objek. Struktur normal dan banyak bergabung adalah cara yang tepat untuk merancang database Anda sebagai buku teks mengajarkan Anda … tapi ketika berhadapan dengan data besar bisa recepie bencana. Masalahnya bukan data ukuran – Data dinormalisasi biasanya menjadi lebih kecil, tapi secara dramatis meningkatkan jumlah pencarian indeks yang bisa akses acak. Masalah ini ada untuk semua jenis aplikasi, namun untuk aplikasi OLTP dengan permintaan pemeriksaan hanya beberapa baris itu adalah kurang dari masalah. Pengambilan data, pencarian, DSS, aplikasi intelijen bisnis yang perlu menganalisa banyak baris menjalankan agregat dll adalah ketika masalah ini adalah yang paling dramatis. Beberapa bergabung juga lebih baik daripada yang lain. Misalnya jika Anda memiliki bintang bergabung dengan meja dimensi yang kecil itu tidak akan memperlambat segalanya terlalu banyak. Di sisi lain bergabung dari beberapa meja besar, yang benar-benar disk yang terikat bisa sangat lambat. Salah satu alasan mengangkat masalah ini dalam MySQL adalah kurangnya canggih bergabung metode pada saat ini (pekerjaan adalah tentang cara) – MySQL tidak bisa melakukan hash bergabung atau mengurutkan merge bergabung – hanya dapat melakukan metode loop bersarang yang membutuhkan banyak lookup indeks yang mungkin acak. Berikut ini adalah contoh yang baik. Seperti yang kita lihat baris 30mil saya (12GB) tabel-scan dalam waktu kurang dari 5 menit. Sekarang jika kita akan melakukan eq join tabel untuk lain baris tabel 30mil dan akan benar-benar acak. Kita harus melakukan 30 juta baris acak membaca, yang memberi kami 300.000 detik dengan 100 baris / tingkat sec. Jadi kita akan pergi dari 5 menit untuk hampir 4 hari jika kita perlu melakukan bergabung. Beberapa orang beranggapan bergabung akan menjadi dekat dengan dua meja penuh scan (sebagai 60mil baris perlu dibaca) – ini adalah cara yang salah. Jangan mengambil saya sebagai melawan normalisasi atau bergabung. Ini adalah prinsip yang besar dan harus digunakan bila memungkinkan. Hanya jangan lupa tentang implikasi kinerja merancang sistem dan tidak mengharapkan bergabung untuk bebas. Akhirnya saya harus menyebutkan satu lagi MySQL keterbatasan yang mengharuskan Anda untuk berhati-hati bekerja ekstra dengan set data yang besar. Dalam MySQL query tunggal berjalan sebagai single thread (dengan exeption MySQL Cluster) dan MySQL isu IO permintaan satu per satu untuk eksekusi query, yang berarti jika satu waktu eksekusi query adalah kekhawatiran Anda banyak hard drive dan sejumlah besar CPU tidak akan membantu. Kadang-kadang ide yang baik untuk secara manual dibagi menjadi beberapa permintaan, berjalan secara paralel dan agregat hasil set. Jadi jika Anda sedang berhadapan dengan set data yang besar dan pertanyaan kompleks di sini adalah beberapa tips Cobalah untuk menyesuaikan data set Anda bekerja dengan dalam memori – Pengolahan dalam memori jauh lebih cepat dan Anda memiliki seluruh banyak masalah diselesaikan hanya melakukannya. Gunakan beberapa server untuk menjadi tuan rumah bagian dari kumpulan data. Toko sebagian data Anda akan bekerja dengan dalam tabel sementara dll Memilih meja penuh scan untuk akses index – Untuk data besar set meja penuh scan seringkali lebih cepat dari kisaran scan dan jenis-jenis pencarian indeks. Bahkan jika Anda melihat 1% atau baris atau scan meja penuh kurang mungkin lebih cepat. Hindari bergabung ke tabel besar Bergabung data yang besar set menggunakan loop bersarang sangat mahal. Cobalah untuk menghindari hal itu. Bergabung ke meja kecil OK tetapi Anda mungkin ingin memuatnya ke memori sebelum bergabung sehingga tidak ada IO acak diperlukan untuk mengisi cache. Dengan arsitektur aplikasi yang tepat dan desain tabel Anda dapat membangun aplikasi yang beroperasi dengan data yang sangat besar set didasarkan pada MySQL

Mewawancarai orang-orang untuk kami Openings Pekerjaan saya ingin meminta mereka pertanyaan dasar – jika Anda memiliki sebuah server dengan 16GB RAM yang akan didedikasikan untuk MySQL dengan database yang besar dengan menggunakan InnoDB beban kerja Web khas pengaturan apa yang akan Anda menyesuaikan dan cukup menarik kebanyakan orang gagal datang dengan sesuatu yang wajar. Jadi saya memutuskan untuk menerbitkan jawaban yang saya ingin mendengar memperluas dengan dasar-dasar Hardware OS Dan optimasi Aplikasi.
Saya menyebutnya InnoDB ini Optimasi Kinerja Dasar jadi ini adalah panduan umum yang bekerja dengan baik untuk berbagai aplikasi, meskipun pengaturan optimal tentunya tergantung pada beban kerja.

Perangkat keras
Jika Anda memiliki database yang besar InnoDB Memory ukuran adalah yang terpenting. 16G-32G adalah nilai biaya efisien hari ini. Dari sudut pandang CPU 2 * Dual Core CPU tampaknya melakukannya dengan sangat baik, sementara bahkan dengan hanya dua Quad Core CPU masalah skalabilitas dapat diamati pada banyak beban kerja. Meskipun ini tergantung pada aplikasi banyak. Yang ketiga adalah IO Subsystem – penyimpanan langsung terpasang dengan banyak spindle dan RAID dengan baterai didukung cache taruhan yang baik. Biasanya Anda bisa mendapatkan 6-8 hard drive dalam kasus standar dan seringkali cukup, sementara kadang-kadang Anda mungkin membutuhkan lebih. Juga perhatikan baru 2,5 “SAS hard drive. Mereka kecil tetapi sering lebih cepat daripada yang lebih besar. RAID10 bekerja dengan baik untuk penyimpanan data dan untuk membaca-kebanyakan kasus ketika Anda masih ingin beberapa RAID5 redundansi dapat bekerja cukup baik juga tetapi jangan acak menulis untuk RAID5.

Sistem Operasi
Pertama – menjalankan sistem operasi 64bit. Kami masih melihat orang-orang berjalan 32bit Linux pada kotak yang mampu 64bit dengan banyak memori. Jangan lakukan ini. Jika menggunakan Linux LVM pengaturan untuk direktori database untuk mendapatkan cadangan lebih efisien. EXT3 file sistem bekerja OK dalam banyak kasus, meskipun jika Anda berjalan di hambatan tertentu dengan itu mencoba XFS. Anda dapat menggunakan opsi noatime dan nodiratime jika Anda menggunakan innodb_file_per_table dan banyak tabel meskipun Manfaat ini adalah kecil. Juga pastikan Anda bergulat OS sehingga tidak akan menukar MySQL dari memori.

MySQL Pengaturan InnoDB
Yang paling penting adalah:
innodb_buffer_pool_size 70-80% dari memori merupakan taruhan yang aman. Saya set ke 12G pada kotak 16GB.
UPDATE: Jika Anda sedang mencari rincian lebih lanjut, lihat panduan rinci tentang tala InnoDB kolam penyangga
innodb_log_file_size – Hal ini tergantung pada kebutuhan kecepatan pemulihan Anda tetapi 256M tampaknya menjadi keseimbangan yang baik antara waktu pemulihan yang wajar dan kinerja yang baik
innodb_log_buffer_size = 4M 4M baik untuk kebanyakan kasus kecuali Anda perpipaan gumpalan besar untuk InnoDB dalam kasus ini meningkatkannya sedikit.
innodb_flush_log_at_trx_commit = 2 Jika Anda tidak kekhawatiran tentang ACID dan dapat kehilangan transaksi atau dua detik terakhir dalam kasus penuh OS kecelakaan daripada menetapkan nilai ini. Hal ini dapat efek dramatis terutama pada banyak transaksi menulis pendek.
innodb_thread_concurrency = 8 Bahkan dengan saat InnoDB Perbaikan Skalabilitas memiliki konkurensi terbatas membantu. Jumlah sebenarnya mungkin lebih tinggi atau lebih rendah tergantung pada aplikasi Anda dan standar yang layak mulai 8
innodb_flush_method = O_DIRECT Hindari double buffering dan mengurangi tekanan swap, dalam banyak kasus pengaturan ini meningkatkan kinerja. Meskipun hati-hati jika Anda tidak memiliki baterai didukung Cache RAID seperti ketika menulis IO mungkin menderita.
innodb_file_per_table – Jika Anda tidak memiliki terlalu banyak tabel menggunakan pilihan ini, sehingga Anda tidak akan memiliki terkendali InnoDB tablespace pertumbuhan utama yang Anda tidak dapat kembali. Pilihan ini telah ditambahkan di MySQL 4.1 dan sekarang cukup stabil untuk digunakan.

Juga memeriksa apakah aplikasi Anda dapat berjalan dalam modus isolasi BACA-commited – jika tidak – set menjadi default transaksi isolasi = BACA-BERTEKAD. Opsi ini memiliki beberapa manfaat kinerja, terutama dalam mengunci 5.0 dan bahkan lebih untuk datang dengan MySQL 5.1 dan replikasi tingkat baris.

Ada banyak pilihan lain yang mungkin ingin menyetel tapi mari kita fokus hanya pada yang InnoDB hari. Anda dapat memeriksa tentang menyetel opsi lain di sini atau membaca salah satu dari kami Presentasi MySQL .

Aplikasi tuning untuk InnoDB
Terutama ketika datang dari latar belakang MyISAM akan ada beberapa perubahan yang Anda ingin lakukan dengan aplikasi Anda. Pertama pastikan Anda menggunakan transaksi ketika melakukan update, baik demi konsistensi dan untuk mendapatkan kinerja yang lebih baik. Selanjutnya jika aplikasi Anda memiliki apapun menulis bersiaplah untuk menangani deadlock yang mungkin terjadi. Ketiga Anda ingin meninjau struktur meja Anda dan melihat bagaimana Anda bisa mendapatkan keuntungan dari sifat InnoDB – pengelompokan berdasarkan primary key, memiliki kunci utama dalam semua indeks (sehingga tetap primary key pendek), pencarian cepat dengan kunci primer (mencoba untuk menggunakannya dalam bergabung), indeks membongkar besar (coba yang mudah pada indeks).

Dengan laras kinerja InnoDB dasar Anda akan lebih baik ketika mayoritas pengguna InnoDB yang mengambil MySQL dengan standar menjalankannya pada hardware tanpa baterai didukung cache yang tanpa perubahan OS dan tidak memiliki perubahan yang dilakukan pada aplikasi yang ditulis dengan tabel MyISAM dalam pikiran.