Mysql_stmt_execute error: *Incorrect string value: '\xF0\x9D\x91\x83\xF0\x9D…' for column 'body' at row 1* (errno: 1366) The restore procedure is to deploy piler, then restore the previously saved files and directories mentioned above. #2: backup the piler, sphinx data, and the configs The restore procedure in this case is to deploy piler from scratch, then import all the saved emails. #1: every day export yesterday emails, eg. Your mileage may wary, so be sure to check out the mysql documentation for innodb!
#DISK ARCHIVE NOTATION ARCHIVE#
Quite often the default settings are not enough beyond a certain archive size, because you need bigger buffers, etc.Īs a guideline, consider my settings for a not that large archive. Several key information, data are stored in mysql, so you have to make sure mysql has all the resources it needs to perform properly. To fix it either upgrade to 1.3.4 or edit src/extract.c, recompile piler. Version 1.3.1 has an issue extracting textual data from attachments: it fails to close a file descriptor when done, so you eventually run out of available file descriptors, that's why pilerimport stops. Pilerimport fails to import all emails from a directory, eg. Use double quotes inside of single quotes, eg.
Pilerimport: IMAP username cannot contain spaces
#DISK ARCHIVE NOTATION UPDATE#
Update metadata set retained = sent + 86400*180
#DISK ARCHIVE NOTATION HOW TO#
How to change the retention for all emails?Ĭonnect to the piler mysql database, then run the following SQL statement to set the retained column to 180 days: I've used Scaleway to host the various instances and run Ubuntu Xenial 64-bit.Ī) VC1S instance (2 X86 64bit Cores, 2GB memory), 3 piler child processes:ī) VC1L instance (6 X86 64bit Cores, 8GB memory), 7 piler child processes: Note that they were artificial emails without any attachment to prevent any external helper utility to introduce a performance penalty. The messages were generated by smtp-source (part of the postfix package). The aim of this was to eliminate any network issue. It sent 10,000 of 100 kB messages to piler to the localhost using 20 concurrent connections. I was running the following command to test: I've done the following performance testing on various configurations: number of CPU cores, memory, disk IO, network speed, as well as application settings (especially mysql innodb parameters, see below) etc.
The available performance depends on the HW capacities you have, eg. If you know that's the case for you in advance, then try using xfs with blocksize of 1024. The latter might be significantly larger especially with bigger block sizes when you have mostly small messages. There's a difference between the apparent size and the size occupied on disk. ext4, xfs, …) and its settings affects the used disk space. Piler stores emails and attachments as distinct files in the filesystem.
0 kommentar(er)
