When you need to see the running processes on your Linux in real time, you have top as your tool for that.
top also displays other info besides the running processes, like free memory both physical and swap
Usage
top [options]
Options

-d ss.tt

Delay -- Specifies the seconds and tenths of seconds of delay between the updates of the info showed on the screen, being the default 3 seconds

-i

Starts top with the last remembered 'i' state reversed. When this toggle is Off, tasks that are idled or zombied will not be displayed.

-n n

Specifies the maximum number of iterations, or frames, top should produce before ending.

-p n

Monitor only processes with specified process IDs. This option can be given up to 20 times, or you can provide a comma delimited list with up to 20 pids. Co-mingling both approaches is permitted. This is a command-line option only. And should you wish to return to normal operation, it is not necessary to quit and and restart top -- just issue the '=' interactive command.

-s

- Secure - Runs top in secure mode, restricting the commands you can use while top is running even for root

-S (Sum)

Starts top with the last remembered 'S' state reversed. When 'Cumulative mode' is On, each process is listed with the cpu time that it and its dead children have used. See the 'S' interactive command for additional information regarding this mode.

Description of the fields

a: PID -- Process Id

The task's unique process ID, which periodically wraps, though never restarting at zero.

b: PPID -- Parent Process Pid

The process ID of a task's parent.

c: RUSER -- Real User Name

The real user name of the task's owner.

Unlike the majority of database systems, MySQL offers a number of table types. Choosing the correct type can be critical for your web application, but few developers realise the implications until it is too late. In this article we examine MyISAM tables.MyISAM is the default MySQL table type. If you have never knowingly specified a type, your table will use the MyISAM engine. There are several reasons why that could be an advantage.

1. Simplicity
MyISAM tables are simple. If you are new to MySQL or databases in general, I would recommend you start with MyISAM tables.
In the following example, we will create a new database and table from the mysql> command prompt. (You do have MySQL installed, right? If not, take a look at How to Install MySQL.)

CREATE DATABASE mysqltest;
USE mysqltest;
CREATE TABLE mysqltest.articles (
id int UNSIGNED NOT NULL AUTO_INCREMENT,
title TEXT NOT NULL,
body MEDIUMTEXT,
PRIMARY KEY (id))
ENGINE = MyISAM;

This creates a new database, mysqltest, and a new table named articles with the columns id (an automatically generated number), title and body. Determining the best column data type is about as complex as it gets.

2. Speed
MySQL is fast. Really fast. Under normal conditions, benchmarks show that MyISAM tables beat every other general-purpose database and uses fewer system resources.

3. Full-text searching
Consider our table above. What if we need to search for keywords in both the title and the body? An easy solution is to add a fulltext index:

ALTER TABLE mysqltest.articles ADD FULLTEXT alltext (title, body);

We can now find all articles that feature the words “database” and/or “article” using:

SELECT * FROM mysqltest.articles
WHERE MATCH(title, body) AGAINST ('database article');

We can even order articles by the most relevant first to create a simple search engine:

SELECT *, MATCH(title, body) AGAINST ('database article') AS rel
FROM mysqltest.articles
ORDER BY rel DESC;

The disadvantages of MyISAM tables

There are several situations when MyISAM may not be suitable.
1. Poor data integrity
MyISAM tables do not support transactions or foreign key constraints.
Consider a banking application where you are transferring money. This would typically involve two SQL UPDATE statements; a debit from one account and a credit to another. If MySQL or the server failed at the wrong point, you could end up with money in both accounts or neither.

2. Poor crash recovery
MySQL is reliable, but MyISAM tables can become corrupt following a crash. The problem can usually be fixed using REPAIR TABLE but it is an additional administrative overhead.

3. Table locking
MyISAM uses table-level locking. When a row is inserted or updated, all other changes to that table are held up until that request has been completed.
It is not always easy to prove whether this will cause problems for your web application but, in general, if you are performing more inserts/updates than selects, MyISAM may not be the best table type to choose.

Should you use MyISAM?

MyISAM is an ideal choice if you are new to MySQL, your web application is simple, has to be fast, or use full-text searches. However, it should not be used when data integrity is a priority. Possible applications could include content management systems, online bookmarking tools, RSS readers, or simple search engines.
Note that you can mix table types within the same database. In practice, it may cause less developer confusion if you stick with a single table type.
See also:

• MySQL: the Pros and Cons of InnoDB Tables
• How to Install Apache
• How to Install PHP
• How to Install MySQL
• How to Use MySQL Foreign Keys for Quicker Database Development

MySQL: the Pros and Cons of InnoDB Tables

 Following on from our look at MyISAM tables, today we examine InnoDB tables.
InnoDB is less well known than the default MyISAM table type. However, there are several reasons why it could be better choice for your web application.

1. Data integrity and foreign key constraints
Foreign keys establish a relationship between columns in one table and those in another. For example, you might create a library application where books can be loaned to members. A foreign key constraint would ensure that a member existed before a book could be checked-out. Similarly, removing a user would not be possible until all their books were returned.
For further information about foreign keys and automating your database, refer to How to Use MySQL Foreign Keys for Quicker Database Development.

2. Transactions
InnoDB tables support transactions. A transaction allows multiple SQL commands to be treated as a single and reliable unit.
Consider a banking application where you are transferring money from one account to another. The transaction would only be committed if both accounts were altered successfully. If anything failed, the database would be rolled-back to a previous state.
In addition, InnoDB tables recover well from crashes. MySQL will analyze the log files to ensure the data is accurate so there is no need to repair tables.

3. Row-level locking
InnoDB uses row-level rather than table-level locking. If a row is being inserted, updated or deleted, only changes to the same row are held up until that request has completed. Tables that receive more updates than selects may be faster with InnoDB.

The disadvantages of InnoDB tables

There are a number of situations when InnoDB may not be suitable.
1. Increased complexity
Creating an InnoDB table is no more complex than MyISAM, e.g.

CREATE TABLE employee (
id smallint(5) unsigned NOT NULL,
firstname varchar(30),
lastname varchar(30),
PRIMARY KEY (id)
) ENGINE=InnoDB;

However, designing that database with foreign key relationships does require more effort. Database novices will find MyISAM easier because it has fewer features.

2. No full-text search
InnoDB tables do not support full-text searches; it is not easy to match one or more keywords against multiple columns.

3. Slower performance
If your application is primarily selecting data and performance is a priority, MyISAM tables will normally be faster and use fewer system resources.

Should you use InnoDB?

InnoDB is the best option if you need to create a reliable data-driven web application. In many ways, InnoDB is a better default choice than MyISAM:

1. unless you have a significantly large or heavily-used system, the speed differences are likely to be negligible
2. full-text searches can be implemented in other ways, e.g. more complex SQL or server-side search algorithms.

InnoDB is certainly the best choice for online shops, financial applications or any project where data integrity is essential. Defining tables is more complex, but your application will be more robust and may require less server-side code.
Note that you can mix table types within the same database. In practice, it may cause less developer confusion if you stick with a single table type.

REFERENCES
http://blogs.sitepoint.com/mysql-myisam-table-pros-con/

Code:

d@home$ cat re.py
import re
re_string = "{{(.*?)}}"
some_string = "this is a string with {{words}} embedded in {{curly brackets}} to show an {{example}} of {{regular expression}}"
for match in re.findall(re_string,some_string):
        print 'Match->', match

ERROR:

Traceback (most recent call last):
  File "re.py", line 1, in <module>
    import re
  File "/home/nikid/PythonSysadmin/re.py", line 4, in <module>
    for match in re.findall(re_string,some_string):
AttributeError: 'module' object has no attribute 'findall'
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/apport_python_hook.py", line 48, in apport_excepthook
    if not enabled():
  File "/usr/lib/python2.6/dist-packages/apport_python_hook.py", line 21, in enabled
    import re
  File "/home/nikid/PythonSysadmin/re.py", line 4, in <module>
    for match in re.findall(re_string,some_string):
AttributeError: 'module' object has no attribute 'findall'

Original exception was:
Traceback (most recent call last):
  File "re.py", line 1, in <module>
    import re
  File "/home/nikid/PythonSysadmin/re.py", line 4, in <module>
    for match in re.findall(re_string,some_string):
AttributeError: 'module' object has no attribute 'findall'

Solution:
rename the file re.py to another name


Another one

ERROR:

NameError: name 'randint' is not defined

Solution:
Rename the random.py to different name..

REFERENCES
http://www.willmer.com/kb/2007/12/attributeerror-module-object-has-no-attribute-blah/