Memcached source code analysis ----- install, debug, and read the memcached source code ----- memcached
Reprinted please indicate the source: http://blog.csdn.net/luotuo44/article/details/42639131
Installation:
Install Libevent before installing memcached. Now it is assumed that the Libevent is installed in the/usr/local/libevent directory.
Because after memcached is installed, there are not as many header files and library files as Libevent. The installed memcached is not used for programming but directly for running. Therefore, you do not need to create a directory for memcached under the/usr/local directory. Install memcached directly to/usr/local.
Decompress memcached-1.4.21.tar.gz in linux, and enter the decompressed directory. Run the following command to configure and install the SDK.
$./Configure -- with-libevent =/usr/local/libevent
$ Make
$ Sudo make install
The default installation directory of memcached is/usr/local. If you want to install it in your own directory, you can use -- prefix = xxx to specify a directory during configure. -- With-libevent indicates the installation directory of Libevent.
If the installation directory is/usr/local, you can run the memcached executable program and enter memcached directly on the command line. In this case, you can run the $ man memcached command to query the help manual.
If it is installed in another directory, such as the/usr/local/memcached directory, some configuration is required. First, you need to modify the PATH environment variable to configure the directory for searching executable files. Add the following at the end of the/etc/bash. bashrc file:
ExportPATH = $ PATH:/usr/local/memcached/bin
Now, you can run the memcached command in shell. However, you cannot use man to query the memcached help manual. Because the help manual of this command is not in man's Query Directory. There is a memcached.1 file in the/usr/local/memcached/share/man/man1 directory. Copy the file to the/usr/local/share/man/man1 directory. Now we can use the memcached.
Debugging:
If memcached has been installed, run the $ sudo make uninstall command to uninstall it. The configure configuration is the same as the previous one and does not need to be changed. Then enter the following command to generate the debug version of memcached.
$ Make CFLAGS = "-g-O0"
$ Sudo make install
That's all. Then, enter the $ gdb memcached command in shell to start memcached. The memcached parameter is entered only after gdb is started and run command is used. As shown in:
Remember to set the breakpoint before using the r or run command.
Start command:
A simple startup command is as follows. Set-l and-p to set the ip address and the listening port respectively. -Vv is the output of some running information.
$ Memcached-l 192.168.1.112-p 8888-vv
Relationship with libevent:
Memcached depends on libevent. You can see from the compilation of memcached. To read memcached code, you need to understand the basic use of libevent. For libevent use examples, refer to Libevent use examples, from simple to complex. Of course, to read the memcached source code, you do not need to read the libevent source code as the basis and understand the basic use of libevent. If you want to read the source code of libevent, you can refer to the libevent source code analysis series.
Comparison with libevent source code:
Although memcached has much less code than libevent, it is much harder to read than libevent. The main reasons are: memcached uses a large number of global variables; each module is highly correlated; a large number of locks and multithreading are used. Each module of libevent is relatively independent, and there are few associations between modules. Basically, each module completes its own functions and then provides APIs for the outside world. Therefore, read the memcached code with patience. In addition to using libevent, read memcached source code also needs to understand the basic usage of multithreading, socket, and pipelines. Of course, if you have read "Advanced Programming in UNIX environment", there is no problem.
Read the source code of memcached:
1. Find an article describing memcached in general. Measure the test taker's knowledge about the technologies used by memcached and various modules in memcached (such as hash tables, slab Memory splitters, LRU queues, and semi-synchronous and semi-asynchronous ). Let's take a look at the complete memcached profiling written by a Japanese. The code is not involved in this article, but a brief introduction to memcached.
2. Read the code in different modules. You can read the slabs. c file, assoc. c file, and items. c file separately. After reading the basic functions of a module, read the functions of another module. Remember, don't try to fully understand the entire module once. Memcached modules are highly correlated and cannot be understood at one time. You should often look back at the previous modules, especially the related things (such as global variables ).
3. Although it is easier to read sub-modules, it is still a little difficult for memcached. Because memcached modules are highly correlated, they are not as open as libevent. Generally, the association uses some global variables. However, memcached uses many, many, and many global variables. Therefore, read the code and check whether the global variables have static modifiers ). In addition, when reading a module, assume that the global variables take the default value and do not change. This makes reading easier. A considerable number of global variables are member variables of the structure variable settings. Many members of the global variable settings can set parameters when starting memcached. However, when reading the settings, it is assumed that the settings are not set. All members use the default value. The settings_init function is used to assign default values to each member of the global variable settings. We recommend that you enable this function every time you read the code to view the default values of each member at any time.
4. memcached uses a large number of locks and multiple threads (non-worker threads). Ignore these locks and threads during reading. When the lock is displayed, It is skipped. It is assumed that no lock is thread-safe. For non-worker threads, it is assumed that there is no such thread. Haha!
5. Some features are available only when enabled, such as the LRU crawler feature. When reading the code, assume that this function is not enabled. This function is usually enabled or disabled based on the value of the global variable. When you see this global variable, you can directly take it as the disabled value.
For the code reading sequence, refer to the writing sequence of this series of blog posts. In simple terms, it is from simple to complex, from a single structure to the overall.
Refer:
Http://blog.csdn.net/unix21/article/details/15501049