Am Mon, 24 Feb 2014 14:18:17 -0700 schrieb David Boreham <david_list@xxxxxxxxxxx>: > > Found out those files is shared mem written to disk!? So moving it to some > > ram disk seems ridiculous. > > Why? If memory gets doubled into a ram disk, then it's ridiculous. If shared mem and ram disk are shared again, not doubled, then there's nothing wrong it. That would be ok. And it seems linux is smart enough to not double it. Seems /dev/shm uses tmpfs explicitly for mmap(). Ok, then it's not ridiculous. :-) > Now, to get rid of the region and log files you would need to run the > database in a non-transacted mode, or transacted but single-process. Do you mean with DB_PRIVATE and DB_LOG_IN_MEMORY set to on? This way I would get rid of all those files (on disk). I can activate the former one via: nsslapd-db-private-mem: on ... in /etc/dirsrv/slapd-kolab/dse.ldif DB_PRIVATE suppresses __db.00* files, that works. The later one via: log_set_config DB_LOG_IN_MEMORY ... in /var/lib/dirsrv/slapd-kolab/db/DB_CONFIG But DB_LOG_IN_MEMORY doesn't work so far. Even if the Database files are consistent, after a clean shutdown. Without the database logs (or empty ones) the database won't start: libdb: file example_com/id2entry.db has LSN 1/3096458, past end of log at 1/140 And with DB_LOG_IN_MEMORY the log is empty with every restart... I didn't knew those logs are such an important part, and even needed if the database is in a clean state. Is there a way to reset LSNs in Database files? That would solve my problem. If there's no way to reset them, there's no difference in having the log in ram (DB_LOG_IN_MEMORY) or having the whole database in ram (/var/lib/dirsrv/slapd-kolab/db/ as tmpfs). If I have to restore the database on every restart in either case, then it doesn't matter if the database files itself get lost or are persistent. Another solution would be some load_log_into_mem_at_startup()- and save_log_to_disk_on_shutdown()-functions with DB_LOG_IN_MEMORY. With some kind of a "clean"-flag like there is one in filesystems. So with a clean shutdown it could be also started very clean. Then I would only have to recover the database after it has crashed... (e.g. has the "unclean" flag set) hede -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
