Re: [OSM-talk] High load on the rendering servers?

2015-03-10 Thread malenki
On Sun, 08 Mar 2015 15:45:29 +0100,
colliar wrote:

 Sounds like work for the editor software if the api is not capable to
 prevent moving a node hundreds of kilometres.

Even if the API rejects very long ways the editor needs a little work to
output a useful error message like precondition failed (just love that
one) to the user.

Thomas


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] High load on the rendering servers?

2015-03-08 Thread Tom Hughes

On 08/03/15 04:28, Eugene Alvin Villar wrote:

On Sun, Mar 8, 2015 at 6:15 AM, Simon Poole si...@poole.ch
mailto:si...@poole.ch wrote:


Jon Burgess tracked the issue down to a way node being dragged from
Japan to Brazil on the 3rd of this month, creating a very very long way
that increased the rendering time for a large number of tiles at high
zoom levels.


Wow. This constitutes an extremely simple way to mount a DoS attack on
the OSM tileservers. I will have to assume that the Operations WG is
already thinking of ideas on how to prevent this possibility in the future.


I think I can safely say we're not.

Of course if you have a brilliant idea how to do such a thing then I'm 
sure we'd love to hear it.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] High load on the rendering servers?

2015-03-08 Thread Christoph Hormann
On Sunday 08 March 2015, Tom Hughes wrote:
 
  Wow. This constitutes an extremely simple way to mount a DoS attack
  on the OSM tileservers. I will have to assume that the Operations
  WG is already thinking of ideas on how to prevent this possibility
  in the future.

 I think I can safely say we're not.

 Of course if you have a brilliant idea how to do such a thing then
 I'm sure we'd love to hear it.

The OSM inspector already has a display mode for ways with long 
segments - it currently however seems it is not working:

http://tools.geofabrik.de/osmi/?view=geometryoverlays=ways_with_long_segments,long_segments

And it has a fairly low threshold (0.3 degrees - that is ~40km) so it 
highlights quite a lot of stuff.  With an additional layer highlighting 
only the very long segments (like above 300km segment length) you could 
quickly see such issues.  And editors of course also should prominently 
warn about such edits.

-- 
Christoph Hormann
http://www.imagico.de/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] High load on the rendering servers?

2015-03-08 Thread colliar
Am 08.03.2015 um 10:20 schrieb Christoph Hormann:
 On Sunday 08 March 2015, Tom Hughes wrote:

 Wow. This constitutes an extremely simple way to mount a DoS attack
 on the OSM tileservers. I will have to assume that the Operations
 WG is already thinking of ideas on how to prevent this possibility
 in the future.

 I think I can safely say we're not.

 Of course if you have a brilliant idea how to do such a thing then
 I'm sure we'd love to hear it.
 
 The OSM inspector already has a display mode for ways with long 
 segments - it currently however seems it is not working:
 
 http://tools.geofabrik.de/osmi/?view=geometryoverlays=ways_with_long_segments,long_segments
 
 And it has a fairly low threshold (0.3 degrees - that is ~40km) so it 
 highlights quite a lot of stuff.  With an additional layer highlighting 
 only the very long segments (like above 300km segment length) you could 
 quickly see such issues.  And editors of course also should prominently 
 warn about such edits.

Sounds like work for the editor software if the api is not capable to
prevent moving a node hundreds of kilometres.

cu colliar

[1] https://josm.openstreetmap.de/ticket/11215



0xE8F56581.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] High load on the rendering servers?

2015-03-07 Thread Grant Slater
Hi Andrew,

Yes were are aware there is an issue. We haven't yet tracked down the issue.
We have been discussing it in #osm-dev on http://irc.openstreetmap.org today.

Kind regards,
Grant
Part of the OSM sysadmin


On 6 March 2015 at 15:20, Andrew Guertin andrew.guer...@uvm.edu wrote:
 For the past few days, lots of things I've changed haven't had their tiles
 re-rendered, and I noticed that the servers are reporting very high load and
 lots of dropped tiles: http://munin.openstreetmap.org/renderd-week.html

 Based on my (completely uneducated) reading of the graphs there, it looks
 like something is filling the Priority Request Queue and keeping it full,
 and there's very little time for anything else. (It looks like the Request
 Queue and the Low Priority Request Queue are also being kept full).

 Anyone know what's causing this?

 --Andrew

 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] High load on the rendering servers?

2015-03-07 Thread Simon Poole

Jon Burgess tracked the issue down to a way node being dragged from
Japan to Brazil on the 3rd of this month, creating a very very long way
that increased the rendering time for a large number of tiles at high
zoom levels.

Simon

Am 07.03.2015 um 21:39 schrieb Grant Slater:
 Hi Andrew,

 Yes were are aware there is an issue. We haven't yet tracked down the issue.
 We have been discussing it in #osm-dev on http://irc.openstreetmap.org today.

 Kind regards,
 Grant
 Part of the OSM sysadmin


 On 6 March 2015 at 15:20, Andrew Guertin andrew.guer...@uvm.edu wrote:
 For the past few days, lots of things I've changed haven't had their tiles
 re-rendered, and I noticed that the servers are reporting very high load and
 lots of dropped tiles: http://munin.openstreetmap.org/renderd-week.html

 Based on my (completely uneducated) reading of the graphs there, it looks
 like something is filling the Priority Request Queue and keeping it full,
 and there's very little time for anything else. (It looks like the Request
 Queue and the Low Priority Request Queue are also being kept full).

 Anyone know what's causing this?

 --Andrew

 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] High load on the rendering servers?

2015-03-07 Thread Eugene Alvin Villar
On Sun, Mar 8, 2015 at 6:15 AM, Simon Poole si...@poole.ch wrote:


 Jon Burgess tracked the issue down to a way node being dragged from
 Japan to Brazil on the 3rd of this month, creating a very very long way
 that increased the rendering time for a large number of tiles at high
 zoom levels.


Wow. This constitutes an extremely simple way to mount a DoS attack on the
OSM tileservers. I will have to assume that the Operations WG is already
thinking of ideas on how to prevent this possibility in the future.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] High load on the rendering servers?

2015-03-06 Thread Andrew Guertin
For the past few days, lots of things I've changed haven't had their 
tiles re-rendered, and I noticed that the servers are reporting very 
high load and lots of dropped tiles: 
http://munin.openstreetmap.org/renderd-week.html


Based on my (completely uneducated) reading of the graphs there, it 
looks like something is filling the Priority Request Queue and keeping 
it full, and there's very little time for anything else. (It looks like 
the Request Queue and the Low Priority Request Queue are also being kept 
full).


Anyone know what's causing this?

--Andrew

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk