how to look up which files a certain process is manipulating?

Question

In my case it's "rsyslogd",

I find it's consuming up to 170M memory,which is too much,

and I've checked its configuration file located at /etc/rsyslog.conf

and then checked each file written inside it,

but in vain.

How can I look up the file it's currently manipulating and look inside what's going on?

[root@slvdb2 log]# lsof -p `pidof rsyslogd`
COMMAND   PID USER   FD   TYPE             DEVICE    SIZE       NODE NAME
rsyslogd 1965 root  cwd    DIR                8,1    4096          2 /
rsyslogd 1965 root  rtd    DIR                8,1    4096          2 /
rsyslogd 1965 root  txt    REG                8,1  259072    2818209 /sbin/rsyslogd
rsyslogd 1965 root  mem    REG                8,1  142176    1097807 /lib64/ld-2.8.so
rsyslogd 1965 root  mem    REG                8,1 1804136    1097817 /lib64/libc-2.8.so
rsyslogd 1965 root  mem    REG                8,1  143096    1097871 /lib64/libpthread-2.8.so
rsyslogd 1965 root  mem    REG                8,1   88976    1097890 /lib64/libz.so.1.2.3
rsyslogd 1965 root  mem    REG                8,1   93416    1097834 /lib64/libgcc_s-4.3.0-20080428.so.1
rsyslogd 1965 root  mem    REG                8,1   53448    1097874 /lib64/librt-2.8.so
rsyslogd 1965 root  mem    REG                8,1   23208    1098015 /lib64/libdl-2.8.so
rsyslogd 1965 root  mem    REG                8,1   11368    4720595 /usr/lib64/rsyslog/imuxsock.so
rsyslogd 1965 root  mem    REG                8,1   23560    4720591 /usr/lib64/rsyslog/imklog.so
rsyslogd 1965 root  mem    REG                8,1   57808    1097853 /lib64/libnss_files-2.8.so
rsyslogd 1965 root  mem    REG                8,1   19504    4720596 /usr/lib64/rsyslog/lmnet.so
rsyslogd 1965 root  mem    REG                8,1    8584    4720598 /usr/lib64/rsyslog/lmtcpclt.so
rsyslogd 1965 root    0u  unix 0xffff880008a31c40            3909712 /dev/log
rsyslogd 1965 root    1w   REG                8,1     435    4014282 /var/log/messages
rsyslogd 1965 root    2w   REG                8,1 7723905    4014355 /var/log/secure
rsyslogd 1965 root    3w   REG                8,1       0    4014356 /var/log/maillog
rsyslogd 1965 root    4w   REG                8,1   58959    4014359 /var/log/cron
rsyslogd 1965 root    5w   REG                8,1       0    4014357 /var/log/spooler
rsyslogd 1965 root    6w   REG                8,1       0    4014358 /var/log/boot.log
rsyslogd 1965 root    7r   REG                0,3       0 4026531849 /proc/kmsg

Didn't get any clues from the above files ..

Answer 1

lsof is very handy for this, as is fuser.

Answer 2

lsof -p <pid> should do the trick.

Answer 3

You can get an idea about the files that the process has opened in /proc/[pid_of_process]/fd/.

Answer 4

lsof -p `pidof rsyslogd`

Answer 5

If you want to "look inside" the process and see "what's going on" you'll want to use something like strace.

Answer 6

Should do the trick:

/usr/sbin/lsof | grep rsyslogd

Answer 7

You assert that rsyslogd is using "too much" memory (170MB). Too much in comparison to what?

First, start by reading this article. The odds are that rsyslogd isn't using as much memory as you think. If you still think that it is, go learn about rsyslogd. You might also want to browse the source.

Once you've done a little more analysis, you might want to open a dialog with the rsyslogd developers, who are probably in a better position to answer your question.

BTW, it's poor form to ask the same question multiple times -- you'd have been better off editing the original question.

Personally, given that your primary problem seems to be with 'site performance' (presumably web-site), I'd suggest looking at the software that's serving the site itself first, before focusing in on critical OS processes that are used on millions of servers on a daily basis. Yeah, the problem could be that rsyslogd is trying to write log messages to a huge file that needs to be rotated, but it's more likely to be content that is being generated dynamically for every request, when it can (and should be) cached.