<p dir="ltr"><br>
On Jun 13, 2016 14:50, "Mads Kiilerich" <<a href="mailto:mads@kiilerich.com">mads@kiilerich.com</a>> wrote:<br>
><br>
> On 06/11/2016 09:23 PM, Konstantin Veretennicov wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> In light of recent performance troubles with our Kallithea<br>
>> installation we consider migrating its database from SQLite to a more<br>
>> server-friendly engine. What would be a good database-copying tool for<br>
>> SQLAlchemy? So far <a href="https://pypi.python.org/pypi/sqlalchemygrate/">https://pypi.python.org/pypi/sqlalchemygrate/</a> came<br>
>> out of my searches.<br>
><br>
><br>
> Yes, that is what is mentioned on <a href="http://kallithea.readthedocs.io/en/0.3.1/usage/performance.html">http://kallithea.readthedocs.io/en/0.3.1/usage/performance.html</a> . I haven't tried it and it would be good to gather a bit more information about pros and cons and howto.</p>
<p dir="ltr">Thanks. Turned out that Jenkins SCM polling was responsible for overloading Kallithea. We were able to fix it today by switching to hook-based "push notifications".</p>
<p dir="ltr">We may still have to migrate away from SQLite later, but it doesn't seem necessary at the moment.</p>
<p dir="ltr">--<br>
Konstantin</p>
<p dir="ltr">><br>
> Generally, we don't use fancy database features and I think it would be quite easy to massage a sql dump from one dialect to another - combined with creating a new empty database and make a data-only import into it. (This might also be an outcome of the alembic thing Soren is working on.)<br>
><br>
> /Mads<br>
</p>