Recently I have build two small and simple "daemon like" progrz to handle short messages comings from different sources and different channels. One of them stay "listen" on /dev/ttySx, playing some simple protocol, and sends incoming messages through multicast UDP channel, to LAN. Other doing the same task but messages coming from unicast UDP from different LAN ("private" GSM/GPRS APN), here is some what more difficult protocol but no big "wonders". For now, debug/test period I'm using simple bash script to start 3 times the serial "port" and 1 times udp port (stdin and stdout redirected to a log file using bash, stdin simply closed). After each 10 - 20 minutes buffers and cached items got from "free" are increasing about 100K, and after several hours I1m out of memory. When I've stopped all my instances of my progz, memory was not released! Now I'm realized, that my box for testing, on "idle" state - nothing is running, exclude the system and several daemons eating about 4 K of memory in every 5 min!?
Box is a Dell Gn+ with P200MHz MMX, 64 MByte RAM, Debian stable 3.1, kernel 2.6.9 (I need this old release because of the SUNIX serial ports those have kernel patches for this release). No Xwindow, two NIC-s and add-on serial port card (2 ports).
Progz are using "liboop" which are based on "select" for I/O multiplexing, no multithreading.
Any suggestion ... ?

Relax, this is the way Linux manages memory. Cached memory is available for immediate re-use by a program should it be needed. If not (needed), the cached data remain there for fast retrieval.
Many threads on this.

The primary issue is "is it causing *you* problems ???.
If (in the unlikely event) it does cause problems, the behaviour can be changed using the swappiness sysctl. Search here on LQ for how to change it.
Shouldn't be needed in normal environments.

Thanks! You right! I was so much confused that my pritty small progz eating so much memory...;o)