Список таблиц/индексов и их размеров

SELECT relname AS "relation", pg_size_pretty(pg_relation_size(C.oid)) AS "size"
  FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema')
  ORDER BY pg_relation_size(C.oid) DESC
  LIMIT 10;

Смена пароля для пользователя postgres

В консоли ввести: sudo -u postgres psql

Затем: \password postgres

Введите новый пароль и выйдете из psql: \q

hashCode в Java

Существует распространенное заблуждение, что Object.hashCode возвращает адрес объекта в памяти. Когда-то давно, наверное, так оно и было. Например, Dalvik VM до сих пор использует адрес объекта, сдвинутый на 3 бита вправо. Однако такая реализация неудачна: во-первых, последовательно выделяемые объекты будут иметь последовательные хеш-коды; во-вторых, сборщик мусора может передвигать объекты в памяти, меняя их адреса.

Так получилось, что на прошлой неделе я дважды столкнулся с темой вычисления хеш-кода, что и побудило меня написать заметку. Сначала попался на глаза крайне несправедливо заминусованный комментарий. Именно SSSurkv совершенно верно предположил, что для вычисления Object.hashCode используется генератор случайных чисел. – Как так? – спросите вы. – Ведь хеш-код объекта должен оставаться постоянным в течение жизни приложения.

Все верно. Встроенный хеш-код генерируется лишь один раз для каждого объекта при первом вызове метода hashCode(), после чего сохраняется в заголовке объекта для последующих вызовов. Но для первого раза используется именно random! Убедитесь сами, заглянув в исходники OpenJDK (функция get_next_hash).

Вероятно, я бы забыл про этот случай, если бы на днях не столкнулся с реальной проблемой в реальном проекте. Профилируя приложение, среди горячих методов я неожиданно увидел IdentityHashMap.put(), который, на мой взгляд, реализован довольно эффективно. Узким местом оказался System.identityHashCode(), на который IdentityHashMap полагается. Причем медленным был только первый вызов identityHashCode на объекте. Второй и последующие вызовы, как мы теперь знаем, берут сохраненное значение из заголовка.

Но нет худа без добра. Дело в том, что в HotSpot можно выбирать реализацию Object.hashCode с помощью ключа командной строки -XX:hashCode=n (где n от 0 до 5).

0 – Park-Miller RNG (по умолчанию)

1 – f(адрес, глобальное_состояние)

2 – константа 1

3 – последовательный счетчик

4 – адрес объекта

5 – Thread-local Xorshift

Наиболее адекватным, на мой взгляд, является последний – он дает неплохое равномерное распределение, используя только битовые операции, и, что важно для конкурентных алгоритмов, не трогает глобальные переменные. Так, всего лишь добавив ключ JVM -XX:hashCode=5, я магическим образом ускорил свой алгоритм на 30%! Почему этот вариант до сих пор не сделали дефолтным, остается загадкой…

Источник: Откуда растут ноги у hashCode

Настройка RMI

export JAVA_OPTS="-Xms2048m -Xmx4096m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.rmi.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=95.181.174.1"

Зависшие Prepared Transaction в Postgres

Если в базе postgres не удаляется таблица (на запрос drop database сервер выдает ошибку database is being accessed by other users, хотя ни кто базу не использует) или в этой таблице невозможно изменить данные и перезагрузка сервера тоже не помогает, то следует обратить внимание на зависшие распределенные транзакции.

Выполняем запрос: select * from pg_prepared_xacts
Копируем значение поля gid.
Теперь выполняем запрос: ROLLBACK PREPARED 'gid'
где gid - скопированное значение.

Настраиваем Glassfish 3.2 на использование логгера log4j

1. Качаем log4j jar. 
2. Копируем его в директорию Glassfish /lib. 
3. Создаем файл настроек log4j.properties и кладем его в директорию /config домена (например, GLASSFISH_HOME/domains/domain1/config/) 
4. Добавляем опцию JVM Dlog4j.configuration=file:///${com.sun.aas.instanceRoot}/config/log4j.properties 
5. Перезапускаем Glassfish 
6. Profit!!!

Собираем движок v8 JavaScript под Microsoft Visual Studio 2010

1. Качаем исходники v8 с помощью svn-клиента (я использую TortoiseSVN): 
2. http://v8.googlecode.com/svn/trunk/
3. Устанавливаем скриптовый язык Python 2.5 или выше (качать от сюда)
4. Устанавливаем утилиту Scons 1.0.0 или выше (качать от сюда)
5. Открываем консоль командой cmd, переходи в папку с исходниками v8
6. В консоли выполняем: <путь_к_Python'у>\scripts\scons.bat env="INCLUDE:C:\Program Files\Microsoft SDKs\Windows\v7.0A\Include;C:\Program Files\Microsoft Visual Studio 10.0\VC\include,LIB:C:\Program Files\Microsoft SDKs\Windows\v7.0A\Lib;C:\Program Files\Microsoft Visual Studio 10.0\VC\lib"
7. Profit!!!