The actual alert DB has mechanisms that look for that 90% condition, and this triggers the database rotation. The database will start dropping old data to make room for new data, and will drop data until the partition is under 90%.
Now, the other thing that lives in that log partition is the syslog facilities. You can check these out by going to the LEM via SSH, and under APPLIANCE run a "diskusage" command The line you want is the one I've highlighted:
Partition Disk Usage:
LEM: 62% (1.8G/3.0G)
OS: 47% (1.3G/3.0G)
Logs/Data: 8% (17G/234G)
Temp: 4% (224M/5.9G)
Database Queue(s): 4.0K (No alerts queued, 2995136 alerts waiting in memory)
Rules Queue: 2.1M (0 alerts queued, 0 alerts waiting in memory)
Console Queue: 2.1M (0 alerts queued, 0 alerts waiting in memory)
DataCenter Queue: 2.1M (0 alerts queued, 0 alerts waiting in memory)
EPIC Rules Queue: 2.1M (0 alerts queued, 0 alerts waiting in memory)
Forensic Database Queue: 2.1M (0 data queued, 0 data items waiting in memory)
Logs: 3.0M
If you have a very chatty syslog device (like a firewall on debug) it may be writing many logs to the LEM and causing that 90% condition. The LEM will respond by dropping alert data in the database. You can manage this log usage in the APPLIANCE menu with the LIMITSYSLOG and SETLOGROTATE commands. I'd suggest hourly and 24 for the settings if you have a busy syslog environment.