Hi Christian, *
> > No, on the contrary, especially because it is run on so many servers > with limited resources, I'm not willing to waste RAM on pootle-VM > alone, when pootle doesn't need it at all. Please leave the technical discussion aside for a minute. What *we* as a team of localizers need is a working and performant setup to do our translation work. All data that you retreaved from the brazilian pootle server are just peanuts and not relevant for what we need to have in the next few weeks for several reasons: - we had no full localization on the server (but we will have to provide this for 3.4 localization) - hardly any team did full translation on the server, we "only" did bugfixes There were some good reasons to have a rather good equipped server for pootle. We knew, that pootle might be not the perfect solution regarding memory usage, multithreading ... That we now cannot use the initialy planned setup is very unfortunate. But we still need a system that provides similar performance. > > I clearly explained why I'm convinced that it is a memory leak. It > doesn't free the memory, even when the machine is idling for hours. It > doesn't need that memory, since when the worker is replaced by a fresh > one, the functionality still works. No - it is just that this is totally irrelevant in the current situation. Even if pootle has a memory leak, we won't fix this within the next few days. But we need to start translating asap! So - if there is any way to provide more ressources (memory) we should do this and analyze the root cause later (I'm sure, pootle developers are interested to help with this). > > Again: > * I don't have a problem with pootle taking half a day to import the > files for a new release (one time thing, no big deal) > * I don't have a problem with pootle taking very long for the very > first hit of the frontpage after a reboot (system is not rebooted that > often, also no big deal) > * I don't have a problem with restarting pootle server-processes to > workaround the memory-leak (whether you call it leak or not, I > definitely call it leak). It limits the amount of concurrent worker > processes, but that is not a problem since even with just the two as > in the VM, you can easily serve 50 concurrent requests per second > while benchmarking (resulting in being able to handle about 200 > request/second of the frontpage, thus much reserves available. No > problem) Maybe you don't have, but the translators will have a problem with this. So either we can provide more ressources to the VM or we need a different solution. All other discussion is very academic at the moment. regards, André -- Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/www/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
