[OSM-dev] minute diff - max delay

Brett Henderson brett at bretth.com
Sun Aug 15 01:13:47 BST 2010


They're okay.  There were two produced at the same time, but for different
hourly periods.  You need to open the corresponding state file to know what
time each one is for.  324.state.txt contains

timestamp=2010-06-29T18\:00\:00Z

but 325.state.txt contains

timestamp=2010-06-29T19\:00\:00Z



On Sat, Aug 14, 2010 at 7:17 PM, bernhard zwischenbrugger <
bz at datenkueche.com> wrote:

>  Hi
>
> It looks like the hour diffs also have a problem.
> They are on time but sometimes there are zwo files.
>
> example:
> 324.osc.gz 29-Jun-2010 20:02 6.0M
> 325.osc.gz 29-Jun-2010 20:02 46K
>
> Bernhard
>
>
> Am 14.08.10 03:38, schrieb Brett Henderson:
>
> On Sat, Aug 14, 2010 at 9:30 AM, Tom Hughes <tom at compton.nu> wrote:
>
>>  On 14/08/10 00:19, Grant Slater wrote:
>>
>>> On 14 August 2010 00:10, Brett Henderson<brett at bretth.com>  wrote:
>>>
>>>>
>>>> Is anybody aware of anything that happened on that day *other* than the
>>>> database upgrade?  Any new imports, etc.
>>>>
>>>>
>>> The database was fully re-imported (planned and triple backed up) and
>>> the transaction IDs were reset due to this.
>>> zere was able to set the transaction id used by osmosis diff export
>>> because I believe you were not around or weren't available at the
>>> time.
>>>
>>> Also: Postgresql 8.3 ->  8.4. RAID10 on 10 disk to RAID 10 on 16 disks.
>>> RAID stripe size changed from 256KB to 64KB.
>>>
>>
>>  There's not really any great mystery here, we know it was the upgrade to
>> postgres 8.4 (or just as likely the reimport of the db) that triggered it.
>>
>
> Okay.  I didn't realise that a database upgrade had occurred, I thought it
> was only disk/RAID changes.
>
>
>>
>> We just need to get to the bottom of what is making some of the queries
>> run slowly, but it's not a very easy thing to do.
>>
>
> Is it only Osmosis queries that are running slowly?
>
>
>> My assumption was that it was choosing a bad execution plan as the way our
>> schema works tends to confuse Postgres's statistics, but the plan I looked
>> at didn't show any sign of that.
>>
>> Equally it doesn't seem to be a lock contention issue.
>>
>
> Is there anything I can add that might make it easier to investigate such
> as additional query options, log query timings, etc?  I'm not sure what to
> try at this point.  About the only thing I can think to do is to set up a
> local database and try to replicate the problem.  I've been meaning to do
> that but it's not a quick task and I haven't had much time to spend on it.
>
> Brett
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.orghttp://lists.openstreetmap.org/listinfo/dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100815/b7d28f86/attachment-0001.html>


More information about the dev mailing list