Friday, 15 December 2017

Notes on Distributed Systems

Stateful, Stateless designs and Caching  --

1. Stateless designs scale much better than Stateful designs. Take REST based designs.
2. Caching data would lead to stateful designs.
3. Stateless designs can find it difficult to handle caching
4. To design a stateless server with support for caching, start with a stateless server, and add caching in front of the server as the first layer. For e.g. a REST based stateless server with a Memcached layer in front to handle caching.

Tuesday, 12 December 2017


Links to learn on Linux Kernel Network Stack --

http://epickrram.blogspot.in/2016/05/navigating-linux-kernel-network-stack.html
http://lss.fnal.gov/archive/2006/pub/fermilab-pub-06-432-cd.pdf
http://lss.fnal.gov/archive/2006/pub/fermilab-pub-06-432-cd.pdf
http://test-docdb.fnal.gov/0013/001343/001/CHEP06_Talk_132_Wu-Crawford_LinuxNetworking.pdf
https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf
http://dspace.library.iitb.ac.in/xmlui/bitstream/handle/10054/1645/34859.pdf?sequence=3

Distributed System Links Worth Repeat Reading

Catalog of links on distributed systems that are worth reading every now and then --

Memcached --
http://info.couchbase.com/rs/northscale/images/Couchbase_WP_Dealing_with_Memcached_Challenges.pdf
https://blog.serverdensity.com/handling-memcached-failover/

Large Scale Systems --

The Tail At Scale --http://www.barroso.org/publications/AttackoftheKillerMicroseconds.pdf
https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
http://www.dcs.ed.ac.uk/teaching/cs3/ipcs/chord-desc.html

Hyperscale Storage --
https://www.snia.org/sites/default/files/SDC/2016/presentations/keynote_general/MarkCarlson_HyperscaleStorage.pdf

Clustering, HA, Fencing and Stonith --
https://news.ycombinator.com/item?id=6590518
http://pl.atyp.us/2013-10-stonith.html

Why NFS Sucks --
https://www.kernel.org/doc/ols/2006/ols2006v2-pages-59-72.pdf

Record of blogs/articles/papers read

2017-12-12 --

https://software.intel.com/en-us/articles/threading-models-for-high-performance-computing-pthreads-or-openmp
Talks about important differences b/w Pthreads and OpenMP thread apis and highlights the scenarios where each is more appropriate to use.

Important Points (directly copied from the article) --

The following definition of pragmas, taken from Microsoft’s documentation, is one of the clearest explanations: “The #pragma directives offer a way for each compiler to offer machine- and operating system-specific features while retaining overall compatibility with the C and C++ languages. Pragmas are machine- or operating system-specific by definition, and are usually different for every compiler. In C and C++, where they are most commonly used, pragmas have the form: #pragma token-string”.A key aspect of pragmas is that if a compiler does not recognize a given pragma, it must ignore it (according to the ANSI C and C++ standards). Hence, it is safe to place library-specific pragmas in code without worrying that the code will be broken if it compiled with a different toolset.

The OpenMP specification consists of APIs, a set of pragmas, and several settings for OpenMP-specific environment variables. As further revisions have been made to the standard, it has become clear that one of OpenMP’s most useful feature is its set of pragmas. By judicious use of these pragmas, a single-threaded program can be made multithreaded without recourse to APIs or environment variables.

OpenMP offers numerous other pragmas that identify code blocks to thread, scope variables to be shared across threads or local to individual threads, where to sync threads, how to schedule tasks or loop iterations to threads, and so forth. So, ultimately, it provides a medium-grained control over threading functionality. At this level of granularity, which is sufficient for many HPC applications, OpenMP delivers better than most other options on the promise of portability, optimal execution, and, especially, minimized disruption to the codebase.

OpenMP’s pragmas have another key advantage: by disabling support for OpenMP, the code can be compiled as a single-threaded application. Compiling the code this way can be tremendously advantageous when debugging a program. Without this option, developers will frequently find it difficult to tell whether complex code is working incorrectly because of a threading problem or because of a design error unrelated to threading.

Both APIs are portable, but Pthreads offers a much greater range of primitive functions that provide finer-grained control over threading operations. So, in applications in which threads have to be individually managed, Pthreads or the native threading API (such as Win32 on Windows) would be the more natural choice.


Wednesday, 25 February 2015

Difference between PR and NI column values in the output of TOP command

For illustration, I am putting up a snippet of TOP output during one of my sessions --

top - 18:54:23 up 1 day, 23:33,  8 users,  load average: 1.23, 1.08, 1.02
Tasks: 295 total,   3 running, 289 sleeping,   0 stopped,   3 zombie
Cpu(s): 28.4%us,  1.9%sy,  0.0%ni, 67.8%id,  1.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   7941828k total,  7741560k used,   200268k free,    90992k buffers
Swap:  8388604k total,   186344k used,  8202260k free,  1479116k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+ COMMAND                                                                                        
   61 root      39  19     0    0    0 S  0.0  0.0   0:07.02 khugepaged                                                                                     
   60 root      25   5     0    0    0 S  0.0  0.0   0:00.00 ksmd                                                                                           
 4358 rtkit     21   1  164m  976  940 S  0.0  0.0   0:02.09 rtkit-daemon                                                                                   
    1 root      20   0 19352 1260 1032 S  0.0  0.0   0:05.40 init                                                                                           
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.40 kthreadd                                                                                       
    4 root      20   0     0    0    0 S  0.0  0.0   0:04.24 ksoftirqd/0                                                                                    
   19 root      20   0     0    0    0 S  0.0  0.0   0:37.61 events/0                                                                                       
   23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cgroup       
         


I wanted to figure out the difference between the values under PR and NI columns, and I found the answer in the man page of C library function getpriority. The following snippet from the man page is the most relevant and explains the difference very well --
     
The  actual  priority range varies between kernel versions.  Linux before 1.3.36 had -infinity..15.  Since kernel 1.3.43 Linux has the range -20..19.  Within the kernel, nice values are actually represented using the corresponding range 40..1  (since  negative  numbers are  error  codes) and these are the values employed by the setpriority() and getpriority() system calls.  The glibc wrapper functions for these system calls handle the translations between the user-land and kernel representations of the nice  value  according  to  the formula unice = 20 - knice.

My Learnings on Linux: A fabulous diagram of the Linux Kernel I/O Stack, ...

My Learnings on Linux: A fabulous diagram of the Linux Kernel I/O Stack, ...: A fabulous diagram of the Linux Kernel I/O Stack, as copied directly from Wikipedia link http://en.wikipedia.org/wiki/Device_mapper ...

Saturday, 7 February 2015

A fabulous diagram of the Linux Kernel I/O Stack, as copied directly from Wikipedia link http://en.wikipedia.org/wiki/Device_mapper