<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 1/2/2017 8:14 AM, Theodor Foerster wrote:<br>
<blockquote
cite="mid:CAE8OcCzvRwSOFA6BPKTZEvmZNw92Zrox4ht=G+g=iyjK35yBXg@mail.gmail.com"
type="cite">Hi all,
<div>I am currently setting up an OSM instance serving tiles based
on the planet file. The spec is:</div>
<div>- Ubuntu 14.04</div>
<div>- 32 GB RAM, 8 cores, 1 TB of virtual volume (500 MB/sec
throughput)</div>
</blockquote>
<br>
The sequential performance of the drive doesn't matter much for tile
rendering. What is its read IOPS performance like?<br>
<br>
<blockquote
cite="mid:CAE8OcCzvRwSOFA6BPKTZEvmZNw92Zrox4ht=G+g=iyjK35yBXg@mail.gmail.com"
type="cite">
<div>I followed the script by <a moz-do-not-send="true"
href="http://opentileserver.org/">http://opentileserver.org/</a></div>
<div><br>
</div>
<div>I witness utterly bad performance. Parts of the query take
around 300+ seconds. Serving a tile takes approx. 20 minutes (1
tile!).</div>
</blockquote>
<br>
On slower hardware, these times aren't uncommon for zoom 5 metatiles
with a badly optimized style or setup. OSM Bright is also more prone
to these problems.<br>
<br>
<blockquote
cite="mid:CAE8OcCzvRwSOFA6BPKTZEvmZNw92Zrox4ht=G+g=iyjK35yBXg@mail.gmail.com"
type="cite">
<div>autovaccuum and fsync are turned off. The obvious performance
measures have been applied. </div>
</blockquote>
<br>
You should have autovacuum and fsync turned <b>on</b>, but neither
will impact rendering performance. work_mem has some impact on
rendering speed, but really, no PostgreSQL GUCs can significantly
increase low-zoom render speed. The solutions there involve queries,
partial indexes, and pre-rendering low zooms.<br>
</body>
</html>