in reply to Perl solution for storage of large number of small files
Incidentally InnoDB performance tuning tips notes:
Wrap several modifications into one transaction. InnoDB must flush the log to disk at each transaction commit if that transaction made modifications to the database. The rotation speed of a disk is typically at most 167 revolutions/second, which constrains the number of commits to the same 167th of a second if the disk does not fool the operating system.
So one disk rotation is 6msec minimum right there. Are you spreading your tied files across several disks? Do you require every write to be saved to disk physically instantaneously, or can you wait a second or so?
Oh, the other thing is if you have disk to burn you could increase your inode size, on XFS, or mirror your disks for speed. But regardless, it seems that moving to a database implementation now rather than waiting for things to explode might be a good idea. I don't suppose your system could do locking to handle multiple writers, could it? Perhaps more info about what you are actually trying to do would be useful.
Also, I was thinking about a presentation at YAPC::Asia I think it was, about how a large service was built on Perl. Livedoor or Mixy. Anyway they split their indices and tables across different servers (using the first characters of user names IIRC). They built a system capable of easily repartitioning this layout as users increase.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: Perl solution for storage of large number of small files
by diotalevi (Canon) on May 01, 2007 at 00:20 UTC | |
Re^2: Perl solution for storage of large number of small files
by andye (Curate) on May 01, 2007 at 10:29 UTC | |
by mattr (Curate) on May 02, 2007 at 22:14 UTC |