Python exercises – challenges – interview training

Python exercises – challenges – interview training


There’re lot of python resources, but I like very much the next:


Some tips for finding performance issues in Linux

Some tips for finding performance issues in Linux

Sometimes we have some trouble with processes that demands lot of IO. There´s a great tool for that, iotop.

I executed fio, to generate some read stress:

mkdir -p /tmp/data ; fio –runtime=300 –time_based –name=random-read –rw=randread –size=128m –directory=/tmp/data

As you could see, fio is on the top of the iotop’s view, and the io is at 99%, displaying the DISK READ K/s.

If you don´t have iotop, you could do it with a little script. It´s not going to give you all that information that iotop shows, but is really good.

Basicly, this script shows the process in “D” State. Processes that are waiting for I/O are commonly in an “uninterruptible sleep” state or “D”; given this information we can simply find the processes that are constantly in a wait state.

cd /proc ; for pid in [0-9]* ; do awk ‘$2 == “D” {print “The process with PID: ‘${pid}’ is in ‘D’ State”;}’ $pid/status ; done

You could see some detailed information with iostat.

iostat -xdy 2 5 (x= Display extended statistics, d= Display the device utilization and y= Omit first report with statistics since system boot)

We see that, %util is very high. It´s very useful to see the r/s w/s (In this case the problem are the reads)

Sometimes we could reach the limit of “open files”.

Error: “Too many open files (24)”

You could see the total of files opened in the system with a simple shell script or lsof:

# for pid in /proc/[0-9]* ; do echo $(ls $pid/fd | wc -l) ; done | sort -n | awk ‘{ SUM += $1} END { print SUM }’

# lsof -Xn -a -d ^mem -d ^cwd -d ^rtd -d ^txt -d ^DEL | wc -l

If you need, to display the info, only for one user, you will need to pass the argument -u $USER to lsof

If you’ve overpassed the user limit, you will need to change this limit with:


Changing the limit for the user: (Edit your .profile and add it or change it
in limits.conf

* ulimit -Hn $NEW_LIMIT ($HOME/.profile)

* Or maybe you will need to do this change globally for all the users, 
editing /etc/sysctl.conf and modifying the value of fs.file-max = $NEW_GLOBAL_LIMIT

Where has all my disk space gone? (linux)

Where has all my disk space gone? (linux)

Sometimes I receive some nagios alerts, displaying a high usage of a filesystem. The first thing I do, a df -h and after that I du -csh /directory (that I suspect could be guilty).

My surprise came after the du, the du tell me /directory is innocent!!! Let me show you an example.

With df we see 17Gb used

The du displays 7.9Gb used! Something strange happens

I´m a bit abset-minded so I start to du -csh /directory1, then /usr/loca/directory200, then /directory3000 until I remember!! Maybe the file is deleted, but not truncated first, and the file descriptor stills open??? !! Ohh, lets see….

So I execute: ‘lsof -X | grep “(deleted)\|COMMAND”|more’ and I see lot of stuff…..

Now I see there are lots of deleted files using space. They are “deleted” but the fd stills open. For example file .out00029 is using 54Mb. The lsof displays the usage in bytes, but we could do “56952801 / (1024.0 * 1024.0) = 54Mb” to get Mb

Now I go to /proc/29937/fd (29937 is the PID of the process that haves the fd open) and I do ls:

This file haves two file descriptors, still used by the PID 29937 (it´s a weblogic server). In the lsof you could see fd 1w and 2w and in the ls you could see 2 and 1, just after the time. The w means that the file descriptor is marked as writeable.

One trick to free that space is to truncate the fd directly. I do it this way, but there are more ways to do it:

# cd /proc/29937/fd and # :> 1 (to truncate file descriptor 1) or # :> 2 (truncate fd 2)

I´ve created a .py for displaying deleted files, that are still in use (fd open) and ordering this fd by size and displaying the location of the fd, so you could truncate it. Take care!! You have to know what you are doing, because you could delete something important.

Now I´m going to put a screenshot of the output of my script. My apologies with my bad code, I´m not a rock star programming, but I try to do it in ‘my’ best way.

And here the location of the .py in my github:

I hope, it could help!!!

Wireshark: How to make sure, you are in the right packet!!

Wireshark: How to make sure, you are in the right packet!!


Some weeks ago, we had a strange issue: We have an hl7 messaging service, and one of the clients that send us some messages, was telling there´s some delay with our queues. We had to put a sniffer in the client, client firewall, server and 4 firewalls that are in our environment.

The client tells us, that some packets are getting stuck for 3 seconds, and we saw that this packet, was retransmitting. Here we could see the first SYN and the tcp retransmission 3 seconds later.

Sometimes, you don´t have the time synchronized in all the systems, so you will need to make sure which packet you are displaying. Here I will show you the Packet bytes pane of the first SYN and below, the packet bytes from the TCP retransmission:

First SYN – Packet bytes pane. The identification value is 0x4253

TCP Retransmission – Packet bytes pane. The identification´s value: 0x4521

Now I will show you the server side *.pcap, where we only see one of the packets. The first SYN wasn´t reaching the server.

Now we could see on the server side, the IP identification of the packet, that corresponds, with the TCP Retransmission. Value: 0x4521

The problem was in the client´s firewall, but the propose of this message, was trying to identify a TCP retransmission packet, because identifying the packet with the time isn´t a good idea.

Maybe this is too obvious for most of you, but I think it could help for some people.