Probably the first two questions to ask are "did you install this on pip3 rather than pip, which is usually the py2 version" and "how did you install synapse?"

> bin/pip --version
pip 18.0 from /home/valodim/cpy/lib/python3.5/site-packages/pip (python 3.5)
> bin/pip install affinity
Requirement already satisfied: affinity in ./lib/python3.5/site-packages (0.1.0)
> bin/python -m synapse.app.homeserver --config-path=/etc/matrix-synapse/homeserver.yaml --config-path=/etc/matrix-synapse/conf.d/
[above error]

synapse is installed in the virtualenv with bin/pip install ./synapse

This is something that should work on Python 3, so I'll take a look. Thanks for the report, @Valodim .

FWIW, it looks like the affinity module hasn't been ported to Python 3, and appears to be a dead project. PyPI says the last release was March 23, 2006, and just importing it in Python3 throws syntax errors around exception syntax:

>>> import affinity
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/srv/matrix.logic.net/venv3.6/lib/python3.6/site-packages/affinity/__init__.py", line 29
    except pywintypes.error, e:
                           ^
SyntaxError: invalid syntax
>>>

That's rather unfortunate.

However, looking at what it actually wraps, I believe a CFFI-using replacement which covers our purposes (Linux only) would be almost trivial to write, so I'll take a stab at that next week.

Do we even need this on Py3? The reason it was added in the first place was due to https://www.mirantis.com/blog/improve-performance-python-programs-restricting-single-cpu/, which i thought might have been addressed in Python 3.5+?

No -- it's up to the operating system to decide where to schedule
something, not the application. Linux schedulers sometimes try and avoid
breaking caches and keep things on the same CPU, but that isn't always the
case.

The problem is that it interacts badly with the implementation of the GIL, since the OS may schedule the threads onto multiple cores, but then the python threads fight/thrash over the GIL locks.

It looks like the GIL may have changed to make it thrash less in python 3.2 http://www.dabeaz.com/python/UnderstandingGIL.pdf ?

If psutil has an implementation, lets just use that. Once we get matrix.org on py3 we should definitely try removing the CPU affinity options to see if the thrashing has indeed been fixed or not, since pinning to a single core does have some performance penalties.

Fixed in #4027