Solution to the problem of not releasing Linux disk space

In the work, we may encounter such a problem, found that a disk space is nearly full, so, find some useless large files deleted it, found that the disk space is still not released, this is why? How to solve it? Here's to reproduce the whole process:

viewing disk space conditions

 [@74.114 var]# df-h
filesystem            size  Used avail use% mounted on
/dev/xvda2             9.7g  284m  8.9g   4%/
/dev/xvda1             251m   13m  226m   6%/boot
none                   1.1g     0  1.1G    0%/dev/shm
/dev/xvda10            97G    60g   33g  65%/home
/dev/xvda3             3.9g  2.7g  1.1g  72%/usr
/dev/xvda5             3.9g  3.6g   77m  98%/var

var partitions are almost full, find large files, and delete

[@74.114 var]# Cd/var
[@74.114 var]# Du–sh *
3.3G Account
111M Cache
53M Log
0 Mail
156K Run
344K Spool
...
[@74.114 var]# RM–RF account/*

Df–h look, but still is/var 98%, not at all released.

[@74.114 var]# df-h
filesystem            Size   Used avail use% mounted on
/dev/xvda2            9.7g  284m  8.9g   4%/
/dev/xvda1             251m   13m  226m   6%/boot
none                   1.1g     0  1.1g    0%/DEV/SHM
/dev/xvda10            97G    60g   33g  65%/home
/dev/xvda3             3.9g  2.7g  1.1g  72%/usr
/dev/xvda5             3.9g  3.6g   77m  98%/var

But Du–sh * shows no big files.

[@74.114 ~]# cd/var && du–sh *
120K Account
111M Cache
53M Log
0 Mail
156K Run
344K Spool
...
Guess 1: The deleted content is still occupied by the process, memory is not released, so with Lsof |grep–i deleted looked at, found as follows:

[@74.114 account]# lsof |grep-i deleted
Listserve 4833 blty 0u CHR 136,2 4/dev/pts/2 (Deleted)
Listserve 4833 blty 1u CHR 136,2 4/dev/pts/2 (Deleted)
Listserve 4833 blty 2u CHR 136,2 4/dev/pts/2 (Deleted)
Billing_p 16989 blty 0u CHR 136,0 2/dev/pts/0 (Deleted)
Billing_p 16989 blty 1u CHR 136,0 2/dev/pts/0 (Deleted)
Billing_p 16989 blty 2u CHR 136,0 2/dev/pts/0 (Deleted)
Billing_p 16990 blty 0u CHR 136,0 2/dev/pts/0 (Deleted)
Billing_p 16990 blty 1u CHR 136,0 2/dev/pts/0 (Deleted)
Billing_p 16990 blty 2u CHR 136,0 2/dev/pts/0 (Deleted)

Billing program occupancy was not released when found, so contact the project manager to stop the billing_p, reboot, and still not release any space. No fruit
Guess 2: Deleted files are accout directory of PACCT files, should be generated and managed by PSACCT, restart the program will be OK? Solve

[@74.114 account]#/etc/init.d/psacct Restart

Finally look at the disk space, disk space to free the bird ~ ~

[@74.114 var]# df-h
filesystem            Size   Used avail use% mounted on
/dev/xvda2            9.7g  284m  8.9g   4%/
/dev/xvda1             251m   13m  226m   6%/boot
none                   1.1g     0  1.1g    0%/DEV/SHM
/dev/xvda10            97G    60g   33g  65%/home
/dev/xvda3             3.9g  2.7g  1.1g  72%/usr
/dev/xvda5             3.9g  100m   3.6m  4%/var

Small suggestion:

When dealing with related issues, if the Du and DF size is found to be inconsistent, you can see through the lsof, you may find some of the reasons for the problem, if you still can not find the problem, if allowed to try to restart the service, perhaps the problem will be solved.
If the restart service is not resolved, you can try to resolve it by uninstalling the disk partition.
Before deciding to delete some files, it is best to determine which services the file is used for, first stop the services and then delete, so that there is little space to release the situation